I'm looking to add a S/PDIF receiver to my blackfin DSP kit and I'm not finding anything that fits. There's some well designed S/PDIF DACs but that's more than I need. If anyone knows of a good quality module please let me know before I waste too many hours duplicating.
Anyway, I working up a CS8416 receiver into a 2" x 4" PCB that will plug onto the Blackfin EZKIT expansion bus. Essentially a fully featured S/PDIF input with an I2S bus programmable by SPI.
A few of my pet must-haves: individual regulators for every IC power pin. (If the chip designer bothered to give us multiple pins, we shouldn't tie them together) complete ground plane, controlled impedance connection for high speed buses with proper drive & termination, surface mount, consideration of EMI issues.
I'm going to build a small number for my own needs but would be willing to share if there's any interest in peer/design review. Quantity discount brings the PCB cost down.
Anyway, I working up a CS8416 receiver into a 2" x 4" PCB that will plug onto the Blackfin EZKIT expansion bus. Essentially a fully featured S/PDIF input with an I2S bus programmable by SPI.
A few of my pet must-haves: individual regulators for every IC power pin. (If the chip designer bothered to give us multiple pins, we shouldn't tie them together) complete ground plane, controlled impedance connection for high speed buses with proper drive & termination, surface mount, consideration of EMI issues.
I'm going to build a small number for my own needs but would be willing to share if there's any interest in peer/design review. Quantity discount brings the PCB cost down.
Sounds like a good idea. I don't have a huge need for a board like this, but I'll certainly throw a bit of help your way. What layout program are you using? If you're using Eagle, I've got part libraries for the Samtec headers and a couple example boards created which use the BF533 expansion headers.
A couple of suggestions:
- Add DIP switches which allow you to connect the CS8416 bit clock and FS outputs individually to the TSCLK0/TSCLK1/RSCLK0/RSCLK1 and TFS0/TFS1/RFS0/RFS1 signals.
- Perhaps even have DIP switches selecting whether the CS8416 drives DR0PRI or DR1PRI.
- Add a spot for a wire, so you can take RMCK from the CS8416 and bring it up to the EZKIT's main board and use it as the MCLK input for the AD1836 chip.
These changes will let you run the onboard codec synchronously with the CS8416's audio input source.
A couple of suggestions:
- Add DIP switches which allow you to connect the CS8416 bit clock and FS outputs individually to the TSCLK0/TSCLK1/RSCLK0/RSCLK1 and TFS0/TFS1/RFS0/RFS1 signals.
- Perhaps even have DIP switches selecting whether the CS8416 drives DR0PRI or DR1PRI.
- Add a spot for a wire, so you can take RMCK from the CS8416 and bring it up to the EZKIT's main board and use it as the MCLK input for the AD1836 chip.
These changes will let you run the onboard codec synchronously with the CS8416's audio input source.
A couple of things I need to research unless anyone knows:
Do the GPO pins have enough drive to source 5mA for the LEDs? I see the logic level specs rated at ±3mA but there's no spec for current limits.
Spec says you can either float the unused S/PDIF lines or tie to ground. Has anyone seen any performance difference? Thoughts?
OK to float OMCLK?
Anyway, thanks gmarsh for some good comments. Oh and BTW, I'm using Orcad.
Do the GPO pins have enough drive to source 5mA for the LEDs? I see the logic level specs rated at ±3mA but there's no spec for current limits.
Spec says you can either float the unused S/PDIF lines or tie to ground. Has anyone seen any performance difference? Thoughts?
OK to float OMCLK?
Anyway, thanks gmarsh for some good comments. Oh and BTW, I'm using Orcad.
My 2 cents,
Cirrus CS8416 has a very bad behaviour with unlocks on input streams with unstable pll. (recovered master clock glitching from ex 256fs nominal value to undetermined one => DACs loves that
)
I do not recommend to use this chip at all for this kind of application.
Cirrus CS8416 has a very bad behaviour with unlocks on input streams with unstable pll. (recovered master clock glitching from ex 256fs nominal value to undetermined one => DACs loves that
)I do not recommend to use this chip at all for this kind of application.
That's strange. The CS8416 is the ONLY receiver Cirrus currently makes. I find it hard to believe they obsoleted the only ones that worked.
Can you elaborate a bit?
What connection were you using - RCA/XLR/optical?
Was this a DIY board or a store bought product?
What was the source?
I'm not connecting to a DAC so I'm not using RMCLK but I assume that if RMCLK is broke then the SDAT/BCLK/LRCLK lines are broke too?
Can you elaborate a bit?
What connection were you using - RCA/XLR/optical?
Was this a DIY board or a store bought product?
What was the source?
I'm not connecting to a DAC so I'm not using RMCLK but I assume that if RMCLK is broke then the SDAT/BCLK/LRCLK lines are broke too?
On the schematic...
The way you've got the AES/EBU input set up, the input signal level can't be greater than 3.3Vpp. Most AES/EBU sources I've seen are 5Vpp square wave (loaded with 110 ohms) and bandwidth limiting pushes the edges up higher than that, to 6-7Vpp. You'll want to divide that down or you might pop the '8416.
I've never encountered any disconnected-input-weirdness problems with a CS8416, though I've never actually designed anything where the input wasn't directly fed into a SRC chip.
If you want to move away from the '8416, I recently used the DIX4192 transceiver from TI and I can't say anything bad about it. It has four real, actual differential inputs. And a transmitter (heh). It does require a +1.8V supply, but in your application I don't think that's a problem 😀
The way you've got the AES/EBU input set up, the input signal level can't be greater than 3.3Vpp. Most AES/EBU sources I've seen are 5Vpp square wave (loaded with 110 ohms) and bandwidth limiting pushes the edges up higher than that, to 6-7Vpp. You'll want to divide that down or you might pop the '8416.
I've never encountered any disconnected-input-weirdness problems with a CS8416, though I've never actually designed anything where the input wasn't directly fed into a SRC chip.
If you want to move away from the '8416, I recently used the DIX4192 transceiver from TI and I can't say anything bad about it. It has four real, actual differential inputs. And a transmitter (heh). It does require a +1.8V supply, but in your application I don't think that's a problem 😀
more good stuff.
So a Pi network on the front end should provide infinite balanced adjustability. I'm going optical so I hadn't thoroughly flushed out the transformer input. I set it for just over 13dB attenuation (seeing as you get 6dB for an impedance matched connection) with standard resistors.
Talking of impedance matched - what do you think about 192KS/s (6MB/s+) through a DIP switch - not exactly impedance controlled. Is this a jitter nightmare about to happen or is 6MHz sufficiently slow?
Anyone else had lock problems with the CS8416? Any votes to abort?
So a Pi network on the front end should provide infinite balanced adjustability. I'm going optical so I hadn't thoroughly flushed out the transformer input. I set it for just over 13dB attenuation (seeing as you get 6dB for an impedance matched connection) with standard resistors.
Talking of impedance matched - what do you think about 192KS/s (6MB/s+) through a DIP switch - not exactly impedance controlled. Is this a jitter nightmare about to happen or is 6MHz sufficiently slow?
Anyone else had lock problems with the CS8416? Any votes to abort?
You could use 74**125 chips with the outputs enabled/disabled by DIP switches, instead of dip switches directly - however, the additive jitter of the gate would probably be more than anything caused by an impedance mismatch through a DIP switch.
The SMT slide types like those on the EZKIT itself are pretty low inductance. IIRC, the EZKIT actually runs a couple of memory interface signals through DIP switches..
The SMT slide types like those on the EZKIT itself are pretty low inductance. IIRC, the EZKIT actually runs a couple of memory interface signals through DIP switches..
Iain McNeill said:
Never had any lock problems on a CS8416, just finished a run of 10 units using this chip and didn't have any problems reported either.
So this is what it turned out like:
pcb layout
I'm quite happy with the layout. The placement keeps the power, digital i/p and digital o/p separated. Bottom side is 100% ground plane. Design rules are very relaxed 10/10.
pcb layout
I'm quite happy with the layout. The placement keeps the power, digital i/p and digital o/p separated. Bottom side is 100% ground plane. Design rules are very relaxed 10/10.
Iain McNeill said:
Cirrus makes pretty good chips but never fully debugged with poor documentation. I have extensive experience using their DACs, codecs, Spdif interface chips and even DSP.
My conclusion after all these years is the following : if you can avoid Cirrus, then do it.
For exemple, look at CS4245 datasheet. Try to find which output pin is left and which is right. (for the DAC)
Now for the CS8416, I've only tested it using RCA and optical. Just pay attention to the behaviour of the recovered master clock when you disconnect the spdif cable or when you interrupt the incoming stream. (nice 256Fs to unknown frequency sweep)
If you don't use ASRC, that Cirrus Chip is definitely not the best master clock provider.
But it will do the job for your current design.
Thanks for the details Johnix. It sounds like you have a better receiver than the CS8614 - care to spill the beanz😉
The fault condition you talk of is a basic problem that S/PDIF receivers must deal with -if the incoming bitstream goes away, the PLL will be open loop, what can it do but drift aimlessly. The 8614 has a number of features to help with this. 1st, you can mute the audio (insert digital zero or just fire an I/O pin) as soon as the PLL loses lock. 2nd, you can set it to switch to an alternate system clock (input on OMCK) instead of the PLL, 3rd by providing a reference clock in slave mode you can set it to give you an interrupt whenever the audio output slips or repeats a sample. The regularity of this interrupt give you a measure of the difference between the source clock and the reference clock. In fact, the CS8614 has an internal register you can read that tells you what the actual source clock is (the TI part only tells you if it's in the 32, 44.1, 48 or "other" frequency window.)
I checked out the TI DIR9001 but it doesn't seem so user friendly. Needs a lot of GPIO to hook up to and only has one input. (It's much cheaper tho') But it too outputs a very wrong reconstructed clock when the input is interrupted.
What behaviour are you looking for? Have you found a part that has this behaviour?
The fault condition you talk of is a basic problem that S/PDIF receivers must deal with -if the incoming bitstream goes away, the PLL will be open loop, what can it do but drift aimlessly. The 8614 has a number of features to help with this. 1st, you can mute the audio (insert digital zero or just fire an I/O pin) as soon as the PLL loses lock. 2nd, you can set it to switch to an alternate system clock (input on OMCK) instead of the PLL, 3rd by providing a reference clock in slave mode you can set it to give you an interrupt whenever the audio output slips or repeats a sample. The regularity of this interrupt give you a measure of the difference between the source clock and the reference clock. In fact, the CS8614 has an internal register you can read that tells you what the actual source clock is (the TI part only tells you if it's in the 32, 44.1, 48 or "other" frequency window.)
I checked out the TI DIR9001 but it doesn't seem so user friendly. Needs a lot of GPIO to hook up to and only has one input. (It's much cheaper tho') But it too outputs a very wrong reconstructed clock when the input is interrupted.
What behaviour are you looking for? Have you found a part that has this behaviour?
Thanks for your feedback.
Even if I haven't tested the AKM parts, the only SPDIF receiver that deliver a real true absolutely clean and fast enough LOCK/UNLOCK signal are the latest chips from TI (SRC4392 for example). Properly configured, this chip keeps deliverering a clean (within 40-60% duty cycle range during transition) 256Fs recovered clock to DACs (DACs dont like glitches on MCLK) with data on I²S to 0.
WM8805 is supposed to feature a gentle transition between PLL-clock and reference clock during lock<=>unlock transitions but unfortunately fails to do it with no interruption of signal and/or with maintained duty cycle.
Anyway, I'll have a new try with the CS8416 😉
Even if I haven't tested the AKM parts, the only SPDIF receiver that deliver a real true absolutely clean and fast enough LOCK/UNLOCK signal are the latest chips from TI (SRC4392 for example). Properly configured, this chip keeps deliverering a clean (within 40-60% duty cycle range during transition) 256Fs recovered clock to DACs (DACs dont like glitches on MCLK) with data on I²S to 0.
WM8805 is supposed to feature a gentle transition between PLL-clock and reference clock during lock<=>unlock transitions but unfortunately fails to do it with no interruption of signal and/or with maintained duty cycle.
Anyway, I'll have a new try with the CS8416 😉
Nice! The SRC4392 is an impressive chip! Just like the DIX4192 that gmarsh recently used but with an ASRC.
The ASRC eliminates S/PDIF jitter issues completely and also provides sample rate flexibility - two functions that I was planning to do on the Blackfin - all for $17.
What else do I like about it?
How about data rates to 24bit/192KS/s, 140dB dynamic range, 16:1 to 1:16 automatic SRC, and a spare serial audio port. Kinda blows the CS8416 out of the water😀
0.02" pin spacing is barely DIY friendly - thats the limit of my soldering skills but I'm game.
One concern: It takes care of the 44.1 to 48K rate conversion and it takes care of jitter but does it really solve the 44.099 to 44.101KS/s interface problem? There's not enough information in the TI datasheet to tell how they did the ASRC. If they up sample the input enough and implement a good frequency tracker that correctly calculates the output decimation phase then it will cope with the slight frequency differences between the source and the processor. If not then the problems of slip and repeat remain.
Has anyone tested the SRC4392 and willing to share results?
The ASRC eliminates S/PDIF jitter issues completely and also provides sample rate flexibility - two functions that I was planning to do on the Blackfin - all for $17.
What else do I like about it?
How about data rates to 24bit/192KS/s, 140dB dynamic range, 16:1 to 1:16 automatic SRC, and a spare serial audio port. Kinda blows the CS8416 out of the water😀
0.02" pin spacing is barely DIY friendly - thats the limit of my soldering skills but I'm game.
One concern: It takes care of the 44.1 to 48K rate conversion and it takes care of jitter but does it really solve the 44.099 to 44.101KS/s interface problem? There's not enough information in the TI datasheet to tell how they did the ASRC. If they up sample the input enough and implement a good frequency tracker that correctly calculates the output decimation phase then it will cope with the slight frequency differences between the source and the processor. If not then the problems of slip and repeat remain.
Has anyone tested the SRC4392 and willing to share results?
ASRC's will fix the "44.09 to 44.11" problem.
The only thing to watch out for is, ASRC's will mangle any "non-audio" data that goes through them. If you ever want to code up a Dolby, DTS or HDCD decoder on the Blackfin, you'll want to be able to bypass the ASRC.
I've used the equivalent SRC4382, and it's a very good chip. You'll be able to implement this "bypass feature" if you want with a register write.
The only thing to watch out for is, ASRC's will mangle any "non-audio" data that goes through them. If you ever want to code up a Dolby, DTS or HDCD decoder on the Blackfin, you'll want to be able to bypass the ASRC.
I've used the equivalent SRC4382, and it's a very good chip. You'll be able to implement this "bypass feature" if you want with a register write.
Thanks gmarsh and johnix. On further consideration I decided to give the SRC4392 a try. Slightly more challenging board - the IC requires 0.008" pad-to-pad spacing and I had to invoke 0.006" trace width and 0.006" trace spacing to save routing the TX+/- lines all round the board. Everything else is still 10/10.
I axed the DIP switches and substituted a zero ohm matrix - less space, less cost and made me feel better about high speed data through complex mechanical parts.
The spare I2S port is brought out to a 2x4 pin header for future expansion.
The transformers are 2:1 center tapped which provides a 6dB attenuation option on receive (selected by C9/C10) or 6dB boost on Tx (assuming the SRC4392 can drive 38ohms.)
So the schematic looks like this:
schematic page 1
power supply
expansion connector
and first cut layout:
layout
I axed the DIP switches and substituted a zero ohm matrix - less space, less cost and made me feel better about high speed data through complex mechanical parts.
The spare I2S port is brought out to a 2x4 pin header for future expansion.
The transformers are 2:1 center tapped which provides a 6dB attenuation option on receive (selected by C9/C10) or 6dB boost on Tx (assuming the SRC4392 can drive 38ohms.)
So the schematic looks like this:
schematic page 1
power supply
expansion connector
and first cut layout:
layout
Final final…maybe.
Added tricky dual part footprint that allows use of either BNC or RCA jacks. Also reworked the electrical S/PDIF input circuit to add a zobel and allow for experimentation in gain structuring, attenuator isolation and level matching after reading Jocko Homo’s TDR crusades in assorted threads (Thanks Patrick!). I took off the XLR pads figuring you could just wire to the BNC pads, there are component options to go single ended or differential.
What I lost was the ability to software switch between multiple inputs and provide multiple S/PDIF conversion capability. (I thought this might be useful as a TOSlink to AES converter etc.etc. or even as a repeater for long haul -like that’s going to help jitter)
Here's new schemo
Added tricky dual part footprint that allows use of either BNC or RCA jacks. Also reworked the electrical S/PDIF input circuit to add a zobel and allow for experimentation in gain structuring, attenuator isolation and level matching after reading Jocko Homo’s TDR crusades in assorted threads (Thanks Patrick!). I took off the XLR pads figuring you could just wire to the BNC pads, there are component options to go single ended or differential.
What I lost was the ability to software switch between multiple inputs and provide multiple S/PDIF conversion capability. (I thought this might be useful as a TOSlink to AES converter etc.etc. or even as a repeater for long haul -like that’s going to help jitter)
Here's new schemo
Comments on design:
The TX+,TX- lines running under the chip, necking down to 6mil and running through the receiver circuits have to be the worst aspect of this layout. This act denies the possibility of top side ground plane under the SRC chip and routing the substrate connection BGND directly to AGND as the datasheet recommends for minimum jitter on RX stream. I did this because I wanted all connectors PCB mounted on the same board edge on smallest board area and I’m relying on the ASRC to solve my jitter issues.
The RF treatment of the S/PDIF RX and TX is suboptimal. Ideally you would use 75ohm microstripline to route the input and output sections but that requires trace widths of 50-60mil on 62mil FR4. The 10mil traces used have an impedance closer to 130ohms. Also the stubs connecting to the BNC connector will no doubt provide a reflection. I could cut off the offending traces if I was concerned. The traces aren’t length matched, this means a slightly different time-of-flight for +ve and –ve traces. The SRC4392 has an input impedance of about 25K on its input-comparator-with-hysteresis which probably needs another pi network impedance transform. That’s three strikes I know but I’m gamboling that the ASRC saves my BE.
2:1 transformers are frowned upon. I see it as an interesting gain management opportunity so I want to try this out myself; but the bottom line is there are 1:1 transformers available in the same package that can be configured on the board as it is.
The AES Tx output trace to the optical transmitter has no impedance management and runs pretty rampant around the input sections. I fear this will be a jitter/locking problem when re-transmitting but for my own application, I intend to turn this feature off. I can explore this if anyone’s interested.
This is a prototype for my own edification and so is not intended to be perfect, just useful enough to collect some data and learn.
I also intend to do a lot of experimentation on the power supply. Some of the LED’s and steady state pull ups are pulled to sensitive supplies such as the optical and analog supplies. These can be isolated if needed, it just made the layout cleaner. I want to see what advantage the 60dB PSRR of the individual TPS regulators has over a single universal supply with inductor-capacitor filters for individual loads. This will have to be performed with flying leads and tombstone inductors – but I think if I can keep the wires on the PCB surface it’ll be good enough.
The TX+,TX- lines running under the chip, necking down to 6mil and running through the receiver circuits have to be the worst aspect of this layout. This act denies the possibility of top side ground plane under the SRC chip and routing the substrate connection BGND directly to AGND as the datasheet recommends for minimum jitter on RX stream. I did this because I wanted all connectors PCB mounted on the same board edge on smallest board area and I’m relying on the ASRC to solve my jitter issues.
The RF treatment of the S/PDIF RX and TX is suboptimal. Ideally you would use 75ohm microstripline to route the input and output sections but that requires trace widths of 50-60mil on 62mil FR4. The 10mil traces used have an impedance closer to 130ohms. Also the stubs connecting to the BNC connector will no doubt provide a reflection. I could cut off the offending traces if I was concerned. The traces aren’t length matched, this means a slightly different time-of-flight for +ve and –ve traces. The SRC4392 has an input impedance of about 25K on its input-comparator-with-hysteresis which probably needs another pi network impedance transform. That’s three strikes I know but I’m gamboling that the ASRC saves my BE.
2:1 transformers are frowned upon. I see it as an interesting gain management opportunity so I want to try this out myself; but the bottom line is there are 1:1 transformers available in the same package that can be configured on the board as it is.
The AES Tx output trace to the optical transmitter has no impedance management and runs pretty rampant around the input sections. I fear this will be a jitter/locking problem when re-transmitting but for my own application, I intend to turn this feature off. I can explore this if anyone’s interested.
This is a prototype for my own edification and so is not intended to be perfect, just useful enough to collect some data and learn.
I also intend to do a lot of experimentation on the power supply. Some of the LED’s and steady state pull ups are pulled to sensitive supplies such as the optical and analog supplies. These can be isolated if needed, it just made the layout cleaner. I want to see what advantage the 60dB PSRR of the individual TPS regulators has over a single universal supply with inductor-capacitor filters for individual loads. This will have to be performed with flying leads and tombstone inductors – but I think if I can keep the wires on the PCB surface it’ll be good enough.
- Status
- Not open for further replies.