Cheff,
There’s no argument that a FF will work well with higher BW loop filters and sources with low drift rates, however once a lower BW loop filer is use – or a source with higher drift is used, then some form of larger memory is required to prevent data loss when there is a large difference between the Master and Slave clocks.
The maximum FIFO size depends on how much drift of the Master clock you want to allow for, and how often you adjust the slave oscillator to keep track of the Master Clock over the longer term. Under normal conditions the VCO in my designs is adjusted every 20 – 30 Seconds which is a couple of orders of magnitude lower then the 3Hz Bocka used. With this longer-term adjustment of the Slave clock – it’s now easy to see why a short depth memory is required.
I the end I did not use Matthys' discrete oscillator, as I need a fundamental mode oscillator at around 100MHz to allow construction of the VCO. I ended up having SAW devices manufactured, and a PECL ASIC masked for the oscillator circuit.
John
There’s no argument that a FF will work well with higher BW loop filters and sources with low drift rates, however once a lower BW loop filer is use – or a source with higher drift is used, then some form of larger memory is required to prevent data loss when there is a large difference between the Master and Slave clocks.
The maximum FIFO size depends on how much drift of the Master clock you want to allow for, and how often you adjust the slave oscillator to keep track of the Master Clock over the longer term. Under normal conditions the VCO in my designs is adjusted every 20 – 30 Seconds which is a couple of orders of magnitude lower then the 3Hz Bocka used. With this longer-term adjustment of the Slave clock – it’s now easy to see why a short depth memory is required.
I the end I did not use Matthys' discrete oscillator, as I need a fundamental mode oscillator at around 100MHz to allow construction of the VCO. I ended up having SAW devices manufactured, and a PECL ASIC masked for the oscillator circuit.
John
Hi JohnW,
using a FIFO seems not the optimum to me, as you have no access to the FIFO write and read counters. As a typical FIFO has (useable) almost emty, half full and almost full flags building a decent feedback controll system is hard to implement. Why not using a dual ported RAM and implement the FIFO with hardware read and write counters? To me this gives a closer coupling between input and reclocked output signals.
A DAC driven VCO is not able to correct the phase to zero, you'll always have a small phase shift, because of the DAC quantisation. A pure analog PLL does not suffer on this, but has other limitations. Just my 2ct.
But John you are right with 20 or 30 seconds of adjusting time I'd also say, that using a simple D-FF is adventurous. On the other side an adaptive filter with phase dependant time constant could lower the bandwidth of a D-FF reclocking stage. If I haven't tested it I cant say if it works or not. No experience with that kind of design.
Isn't that a good example or marketing requirements? What if that esoteric CD player uses a ceramic resonator instead of an XTAL? These ceramics have tolerances of +/- 500 ppm, under best conditions the pull range of a VCXO is abotr +/- 200 ppm. One can always find a feasibility that a given combination of a CD player and a DAC will not work. Or someone has found out, that 5V SPDIF voltage sounds better than the 0.5V given in the specs. Well, some (analog) SPDIF input stages don't like such overload conditions as phase reversal occurs. I don't say that marketing requirements are bad, they are often essential for a business, but in many cases there are not technical reasons crusial for these decisions
using a FIFO seems not the optimum to me, as you have no access to the FIFO write and read counters. As a typical FIFO has (useable) almost emty, half full and almost full flags building a decent feedback controll system is hard to implement. Why not using a dual ported RAM and implement the FIFO with hardware read and write counters? To me this gives a closer coupling between input and reclocked output signals.
A DAC driven VCO is not able to correct the phase to zero, you'll always have a small phase shift, because of the DAC quantisation. A pure analog PLL does not suffer on this, but has other limitations. Just my 2ct.
But John you are right with 20 or 30 seconds of adjusting time I'd also say, that using a simple D-FF is adventurous. On the other side an adaptive filter with phase dependant time constant could lower the bandwidth of a D-FF reclocking stage. If I haven't tested it I cant say if it works or not. No experience with that kind of design.
Isn't that a good example or marketing requirements? What if that esoteric CD player uses a ceramic resonator instead of an XTAL? These ceramics have tolerances of +/- 500 ppm, under best conditions the pull range of a VCXO is abotr +/- 200 ppm. One can always find a feasibility that a given combination of a CD player and a DAC will not work. Or someone has found out, that 5V SPDIF voltage sounds better than the 0.5V given in the specs. Well, some (analog) SPDIF input stages don't like such overload conditions as phase reversal occurs. I don't say that marketing requirements are bad, they are often essential for a business, but in many cases there are not technical reasons crusial for these decisions
Empty and full flags indicate errors so they are not really usable. It's not because you don't have enough memory, the FIFO can't indicate by it's flags if the memory level is half full, half full + 1, half full +2 ... almost full -1 for example. Half full flag is set, almost full flag is cleared, so important information for the control system ist lost. With a dual ported ram you only need to substract the read counter from the write counter value and you get all necessary information for a digital PID control system otherwise you have a two-level controller which has an inherent control deviation
Bocka,
I have no idea what you’re trying to say above – I don’t see where or how “Phase” is important? Phase of what? – both audio channels will always be in phase – no matter what, and for sure there will be a very slight variable delay introduced by the FIFO, from the data arriving at the input, and data output – but this is magnitudes less then the group delay of digital filters – not to mention video processing in AV systems, so I fail to see the relevants of this?
Your obviously have your own personal reasons to dislike the arrangement I use – and therefore have a very closed mind about it – or your failing to grasp the simple facts – which is a shame, as the reason to implement the design is to avoid the sonic disadvantages introduced by ASRC – which was the original intention of mentioning it in this thread.
Any designer of an “Esoteric CD player” who uses an uncorrected ceramic resonator deserves his head examining.
But maybe you missed my point that I use SAW device for my VCO’s – if you have any experience of SAW devices (and obviously you don’t) you would know that these can be pulled in excess of +/- 2000ppm with ease, and yet give very good short-term phase noise (SAW's longer term drift is taken care of by the FIFO Master / Slave Lock).
With your negative attitude to my design you are second guessing it arrangement – the FIFO is implementing in the system FPGA – therefore I have complete control over its design, I know the exact memory status at any instants.
Adventurous??? would you Pls. care to explain how it would be possible to have 2 clocks out of Sync for over 30 seconds and not have data loss with a single D-type FF?
This is the last I have to say on this subject, as I’m quite obviously wasting my time,
John
Hi John,
both phases (refclock of the SPDIF receiver and the VCO clock) are always out of phase in your design which uses a quantisation process to control the phase difference of the two clocks. An analog PLL can control the difference of two phases to zero a digital don't, that are basics.
Yes, thats what I've explained, it can't be done with a discrete FIFO, only with a dual ported ram and a write/read counter. I dislike (most) FPGAs very much, as someone can copy all your work just by reading the configuration EEPROM...
And in this case they are at least one magnitude more sensitive for voltage controlled phase noise and jitter than a VCXO. SPDIF compliance only require +/-100ppm pull range. And for varispeed applications any reclocking with a voltage controlled SAW or XTAL will never work.
No, I do not dislike the arrangement you made by itself.
Yes, your design has also weak points like others too.
I've never offended you personally like you did. But maybe I'm wrong here as you do commercial stuff to make money with and I do Do It Yourself audio what is the intention of this discussion forum. How may people in the DIY area are able to use an ASIC for realising their design goals?
The problem is, that most engineerers aren't able to discuss with each others as they persuaded of their designs and failed to see, that others will do also.
skpb:
There is a bible. So does this guarantee there is a God?
I am presently working with a major epld manufacturer as a 'industry evaluator' for their multichannel AES/SPDIF receiver firmware function. It looks like they've reasonably addressed all the complex issues but I have a gamut of fundamental 'idiot bomb' tests which a good design must resist. For instance if you feed a frequency swept squarewave, (or a sinewave or PN data or the most imaginative rubbish signal you can dream up) into the AES receiver, it must not fall over. It must not issue squawks, hisses, squeals, spits, hisses or pops on the output.
Quite a lot of reworks have been necessary over the last few weeks to achieve this.
The number of logic cells required to implement typical RX-SRC firmware designs is large and unless there is need for a huge FPGA in the project to do other things, an RX-SRC in epld firmware is is seldom justified. However, this is still no excuse to use a CS8420 in a new design!
Cheers
There is a bible. So does this guarantee there is a God?
I am presently working with a major epld manufacturer as a 'industry evaluator' for their multichannel AES/SPDIF receiver firmware function. It looks like they've reasonably addressed all the complex issues but I have a gamut of fundamental 'idiot bomb' tests which a good design must resist. For instance if you feed a frequency swept squarewave, (or a sinewave or PN data or the most imaginative rubbish signal you can dream up) into the AES receiver, it must not fall over. It must not issue squawks, hisses, squeals, spits, hisses or pops on the output.
Quite a lot of reworks have been necessary over the last few weeks to achieve this.The number of logic cells required to implement typical RX-SRC firmware designs is large and unless there is need for a huge FPGA in the project to do other things, an RX-SRC in epld firmware is is seldom justified. However, this is still no excuse to use a CS8420 in a new design!
Cheers
Interesting thread 
Does anybody of you experience the following:
The CS8420 in a certain design dies during plugging and unplugging the SPDIF-connector. There seems to be an issue with electrostatic discharge or something related.
The effect did occure with the same design in different environments or audio systems.
There is not much in front of the CS8420s input excepted a Zener in parallel to have some overvoltage-protection. Originally it is a simple AC-connected SPDIF like... everywhere else.
Special overvoltage-protection diodes did not help, as did the use of transformer-coupling.
The application of a 100R-series Resistor followed by diodes to the supply-rails did not cure this either.
Thank you for help,
Fredi
Does anybody of you experience the following:
The CS8420 in a certain design dies during plugging and unplugging the SPDIF-connector. There seems to be an issue with electrostatic discharge or something related.
The effect did occure with the same design in different environments or audio systems.
There is not much in front of the CS8420s input excepted a Zener in parallel to have some overvoltage-protection. Originally it is a simple AC-connected SPDIF like... everywhere else.
Special overvoltage-protection diodes did not help, as did the use of transformer-coupling.
The application of a 100R-series Resistor followed by diodes to the supply-rails did not cure this either.
Thank you for help,
Fredi
fredi-fritzi said:Interesting thread
Does anybody of you experience the following:
The CS8420 in a certain design dies during plugging and unplugging the SPDIF-connector. There seems to be an issue with electrostatic discharge or something related.
The effect did occure with the same design in different environments or audio systems.
There is not much in front of the CS8420s input excepted a Zener in parallel to have some overvoltage-protection. Originally it is a simple AC-connected SPDIF like... everywhere else.
Special overvoltage-protection diodes did not help, as did the use of transformer-coupling.
The application of a 100R-series Resistor followed by diodes to the supply-rails did not cure this either.
Thank you for help,
Fredi
Fredi,
I had a similar experience, buit it turned out that this was not the problem. The problem was that the 8420 (in this case in a Behringer DCX2496) was wired for AES/EBU interface. "Generally" this works with S/PDIF signals as the protocol is almost identical, however the S/PDIF signal level is much lower than AES/EBU and is just on the border of acceptable to the 8420 in AES/EBU mode.
I built a small signal converter to increase the level and the 8420 has been working fine ever since.
Possibly this could be the case in your situation?
Jan Didden
CS8420 dies
Fredi
I'm assuming by 'dies' you mean ceases to work temporarily, ands will recover when repowered. Not dies as in becomes damaged and needs to be replaced?
If the former, I've had similar experiences. The PLL in the 8420 is not very good (to put it mildly) and I suspect once it becomes unlocked when you remove the input signal, it does not want to lock again when the input signal is restored.
Cirrus are forever changing the PLL design of this chip and there have been several errata bulletins showing changed PLL values. on their website over the lifespan of this chip. I suggest you identify the silicon revision of the 8420 you're using and verify that the PLL components in the circuit are the correct values for that particular revision. If your silicon revision is earlier than D, replace the chip with a new one. The early revs of the 8420 had several insoluble problems.
I always chose the values for 'wide range' as they give the PLL the greatest lock range.
Cheers
Fredi
I'm assuming by 'dies' you mean ceases to work temporarily, ands will recover when repowered. Not dies as in becomes damaged and needs to be replaced?
If the former, I've had similar experiences. The PLL in the 8420 is not very good (to put it mildly) and I suspect once it becomes unlocked when you remove the input signal, it does not want to lock again when the input signal is restored.
Cirrus are forever changing the PLL design of this chip and there have been several errata bulletins showing changed PLL values. on their website over the lifespan of this chip. I suggest you identify the silicon revision of the 8420 you're using and verify that the PLL components in the circuit are the correct values for that particular revision. If your silicon revision is earlier than D, replace the chip with a new one. The early revs of the 8420 had several insoluble problems.
I always chose the values for 'wide range' as they give the PLL the greatest lock range.
Cheers
You dont need to power up/down, It will be ok if you just reset the 8420.
I've put a manual reset that I hit everytime I change the spdif feed.
There is lock indicator pin on the 8420 and if one puts his/her mind to it one could make a automatic reset everytime the PLL cant lock on the input.
I've put a manual reset that I hit everytime I change the spdif feed.
There is lock indicator pin on the 8420 and if one puts his/her mind to it one could make a automatic reset everytime the PLL cant lock on the input.
Hi everybody
I must use the CS8420 in a new design in software control mode (to allow writing to the U-block buffer) with an FPGA and I must allow the users to plug and unplug the AES inputs at any time.
I've thought of monitoring the RERR pin to detect a falling edge (after the PLL has locked again) to set the RUN bit to 0 and then to 1 again, as advised in the datasheet.
My question is : does this pin actually goes back low when the PLL locks again or do I have to read the 'Receiver Error' register until the 'PLL unlock' error disappears ? I have not found the answer to this in the datasheet.
Bonus question : will I have to re-write the U-block buffer after re-running the chip ?
Thanks for the answers !
Regards.
I must use the CS8420 in a new design in software control mode (to allow writing to the U-block buffer) with an FPGA and I must allow the users to plug and unplug the AES inputs at any time.
I've thought of monitoring the RERR pin to detect a falling edge (after the PLL has locked again) to set the RUN bit to 0 and then to 1 again, as advised in the datasheet.
My question is : does this pin actually goes back low when the PLL locks again or do I have to read the 'Receiver Error' register until the 'PLL unlock' error disappears ? I have not found the answer to this in the datasheet.
Bonus question : will I have to re-write the U-block buffer after re-running the chip ?
Thanks for the answers !
Regards.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.