Looking for someone to collaborate on DAC design

[ThorstenL]

Koinichiwa,

I am looking for someone with background in PAL (or similar programmable logic arrays) Programming & Design for co-operation on a DAC project of mine.

The key area of design where I lack skills and tools and have no interest in obtaining such (never mind time) is to do with a FIFO based Databuffer including a retiming via external variable clock (programmable dividers like AD or PLL's like BB) which is controlled to keep a broad sync with the input signal and thus follow it but at the with good short term stability for high jitter rejection.

I have a pretty good idea as to how this can be implemented but no interest to design the neccesary glue logic around CMOS Chips, so programmable logic is needed as glue between this whole shooting match and one would need to draw a PCB (which again I can do but lack the time).

Implementing this well should give a very low Jitter datastream to the actual DAC, regardless how crappy the transport is, while using a standard Cirrus Logic receiver, allowing now theoretically 192KHz/24 Bit operation. For my own use the DAC will be zero oversampling of course and use PCM1704 with some nice tricks.

What I would percieve as doable and possibly interresting for the DIY Audio community is to design the DIR Input and Memory Buffer section as module board, with a buffered clock output on SMA (also an I2S or similar suitable data feed) to feed a reclocker on a DAC Board build by whoever wishes to use the re-timing section.

It matters zip if you stick a Non Oversampling TDA1543 on the end or choose to implement one of the latest newfangled Bitstream/Multibit Hybrids that everyone seems to be so fond of, with gobs of Digital Filtering. Anyones call.

Such a unit may be offered commercially or PCB only by whoever co-operates in the project or be simply published in Audio Express or wherever. This thing may suit an EE Student with a conventional, well measuring DAC on the end as a good final year project as well.

Whoever has the time and interrest to work on this needs to figure out their own angle, as I can't afford to pay for the design effort involved. I would only like to be able to use the results for my own stuff.

I would ideally like someone in the south of England (or even London) so it is possible to meet up and hash out key points over a few pints.

Sayonara

[Pjotr]

First of all, good luck with this project.

Proper implementing PLD’s is not task you learn in a few months indeed.

Please come up with a good block-diagram. Curious about it.

I see no use for shift registers as an “elastic store”. Jitter never crosses the boundaries of the width of the data pulses coming out of a transport unless you have a very, very bad transport. So you are always being able to resample the data directly with an ultra-low-jitter-recovered clock, provided it is a synchronous clock.

Very good PLD design tools are free on the internet:

http://www.latticesemi.com/products/...rter/index.cfm

But be warned. PLD’s are very jittery devices regarding the very low levels of jitter needed for good digital audio.

[ThorstenL]

Koinichiwa,

Originally posted by Pjotr
First of all, good luck with this project.

Proper implementing PLD’s is not task you learn in a few months indeed.

I have used their ancestors in the 1980's, so I supect I can wise up (and I can still program in Assembler), but I really lack the time.

Originally posted by Pjotr

Please come up with a good block-diagram. Curious about it.

Flow chart too for the process? No sweat.

[/B][/QUOTE]

Originally posted by Pjotr

I see no use for shift registers as an “elastic store”.

I do.

Originally posted by Pjotr

Jitter never crosses the boundaries of the width of the data pulses coming out of a transport unless you have a very, very bad transport. So you are always being able to resample the data directly with an ultra-low-jitter-recovered clock, provided it is a synchronous clock.

Sure. What I am really aiming at is a system that does not rely on a "pulled" X-tal (VCXO) for this clock, but uses a mechanism that can be "pulled" from 32KHz to 192KHz AT LEAST.

Using a decent high frequency X-Tal with a suitable programmable and variable downshift will give a low jitter widely pullable clock at very low cost.

Using a long FIFO will allow a very low rate of change in this clock, so it tracks only the AVERAGE frequency of the source, not the actual, eliminating jitter above the cycle of the lowest increment in time of changing the clock.

The clock needs to change only with buffer over- or under-run, using the right combo of buffer and logic gives "varispeed" ability where the larger the rise (or fall) in buffer length the faster the new clock is changed.

And the slower the rate of change in the source clock (usually constant) the lower the rate of change with the new master clock, putting in truely "locked" condition jitter rejection well below the 1Hz mark. Theoretically at least, anyway.

Originally posted by Pjotr

Very good PLD design tools are free on the internet:

Yes, so is Linux. I still pay Bill "W" Gates for his WXP Sotware nevertheless, because I don't have time enough to learn Linux well enough. Yet at work a few minor Servers run Linux and where set up by Students on work experience.

I'm looking for the here. It's not that I cannot, but the poblem to me is ultimatley sufficient peripheral that I cannot be bothered. My current DAC has a dual PLL and is fairly low on jitter, but it is 16/44.1 only.

Originally posted by Pjotr

But be warned. PLD’s are very jittery devices regarding the very low levels of jitter needed for good digital audio.

Which is why want them only for the control functionality to work out if the buffer grows or shrinks (and ideally how fast) and react to this by adjusting the programmed low jitter clock source apropriatley.

All the PAL stuff will be way out of the "signal" lineage and hopefully, once the "lock" has been obtained will be completely inactive at all...

Sayonara

[Pjotr]

Hi,

Thanks for clarifying. If I understand it right you intend to build a digital implemented PLL.

A PLL is basically a narrow band-pass filter concerning side band noise. Whether it is implemented analog or digital, all the basic rules about loop stability, pull range, catch range and so on still remains valid. But what ever you do, you stay limited to the side band noise of the reference (master) oscillator.

The quality of the master oscillator is mainly dependent of de Q-factor of the used crystal, proved the other electronics is done properly.

By building a purely digital PLL, you can’t avoid “clock pulse jumps”, to name it and the associated meta-stability. I am afraid this will do no better than a good PLL with a pulled X-tal oscillator as Guido did.

But I see, you want to build a PLL that is universal for all sampling frequencies in use today. The Crystal receiver chips have flags for frequency detection. If you make use of them you can also use 2 pulled X-tal reference oscillators: One for multiples of 44.1 kHz and one for multiples of 48 kHz. Looks a lot simpler.

For me such a clock upgrade is actual because I want to upgrade the clock circuitry of my M-Audio Superdac.

Regards

[ThorstenL]

Koinichiwa,

Originally posted by Pjotr
Hi,

Thanks for clarifying. If I understand it right you intend to build a digital implemented PLL.

Possibly. I somehow think not. What I have in mind is system that I'm familiar with in process controll applications. Once the "lock" is achieved the system has no or absolutely minimal activity of control, this is certainly not really the case the with analog PLL's I worked with. So there are similarities, but I would contend that the intended principle is superior to an analogue PLL once "lock" has been achieved.

My idea is to have the change of clock "varispeed". If there is a fast buffer "overrun" or "underrun" occuring the clock spped is changed more rapidly, however if you have a very small clock difference you only need to change the clock once every few seconds or even minutes by the smallest step.

The smallest step of programmable clock divided by two determines the maximum deviation between the clocks once "lock" is achieved. The AD9850 has an output tuning resolution of 0.0291Hz.

If we take a CD "retime" master clock of 11.2896MHz and have a FIFO buffer set (wee need three to make that easy to work - thanX to the other Guido for that hint) of the shortest type (256bit each) and aim to allways keep the middle buffer changing between full and empty we should have no activity in the controller once locked for hours at a time.

Yes, such a system will be relatively slow to settle to a full lock, but if we have it on for a while it MUST tend to a minimum deviation. I suspect that simply pre-setting the clock from the input frequency information from the DIR Chip will be enough to keep the first clock change down to a few seconds away.

So an anlogy to the function of a PLL exists but due to the digital nature of the system it is possible to settle to an absolute steady state with no activity.

Originally posted by Pjotr

By building a purely digital PLL, you can’t avoid “clock pulse jumps”, to name it and the associated meta-stability. I am afraid this will do no better than a good PLL with a pulled X-tal oscillator as Guido did.

Sure. But our clock pulse jumps (theoretically) are at 0.0291Hz out of 11.2896 MHz or 0.0026 PPM.

As for Guido's pulled VCXO, to cover 44.1KHz, 48KHz, 88.1KHz, 96KHz, 176KHz and 192KHz sample rates you ned an awfull lot of circuitry.

And all these frequencies may be encountered at some time from the Digital out of a universal DVD Video/Audio Player, depending if you play a DVD Movie, a CD or an Audio DVD. Hance my thought that all these Frequencies must be transparently handeled. And this of course is also the need for the Memory buffer as the clock in these things is positively dibolical.

The downside of this implementation is that it is a little past "kitchen table" electronics, but implemented well and sold as assebled module I suspect you would pick up both OEM's to incorporate this in their gear and it would eb an easy upgrade. Done in SMD the whole board can be tiny.

Sayonara

[daatkins]

Hello,

I’d be interested to hear more about you project as I’ve recently been considering something similar myself, although implemented more in programmable logic.

I’ve recently started using the Lattice 5000MX series CPLD devices at work and the 512 macrocell parts that I use have up to 256 Kbits of memory that can be configured however you like. I’m thinking about implementing a buffer in dual port RAM so the transport clocks the data in and I use an VCXO (or OCXO) to clock it out. I believe this method is used by Chord Electronics in their DAC64 product:
http://195.40.133.90/website/products/dac64.htm

The Lattice devices also have two onboard PLLs with jitter spec’ed at something like 250ps max although they did measure more like 100ps in the lab (application is 20MHz in -> 66MHz out). Not too great really….

The only downside is that most CPLDs and FPGAs are only available in surface mount QFP and BGA packages which make them hard to mount onto a PCB. Hard, but not impossible…..

The pic (assuming it attaches - not shown in preview!) is a Xilinx CPLD which I use in my pre-amp for various duties but mainly for decoding the Sony SIRCS remote control protocol. I did this so that I could use an old Sony TV remote to control volume, source selection, on/off etc. It's a 272-pin BGA dead-beetled and wired to the main PCB. Clock is only 4MHz.

Anyway, I haven’t given my DAC project too much thought so I’m not sure how feasible it is. I’m kind of reluctant to commit to your project (due to a complete lack of time!) but let me know how much glue you need (and what PLD devices you’re considering) and I’ll try to help.

Nice one,
David.

[Petter]

This is all very interesting.

An easy to implement soft buffer would be nice.

What I would like to see is say 64 pins or so feeding discrete current sources with some sort of randomization and at high frequency (sorry Thorsten!)

Or, provisions for feeding a number of parallel DAC chips staggered by a small number of (high frequency) clock cycles. 4-16 parallel staggered DAC chips seems just the ticket .... (they need to be current out for this to work).

And of course it would be nice to get digitally inverted signals to drive single ended DAC's "the other way" to create a balanced output signal.

Anybody else interested in either of these approaches?

Petter

[Pjotr]

Hi,

It looks this becomes a major project. I think it is worth to discuss it more extensively because it is an awful load of work. I think we should limit it to a “jiiter free” data steam/clock to the DAC chip.

Some remarks:

The mentioned AD9850 DDS chip is a nice signal generator. But I have my doubts. Such chips exhibit a large amount of phase noise, or more precisely “phase jumps”, if the ratio of clock frequency and output frequency is not very large. Also the jitter specs of the build-in comparator are not that good.

David, the mentioned PLD’s/CPLD’s are quite expensive for DIY

Regards

[daatkins]

Pjotr,
You're right - I wouldn't recommend using a large CPLD in DIY design collaborations because they are quite expensive. The part I used for my remote control decoder is about $15, plus you need programming hardware, logic simulator, logic synthesiser and the place & route software. The synthesiser we use at work is something like $10,000 a license!

I use them in my projects because I have access to all the tools at work and I know the Altera, Lattice and Xilinx guys very well so I can get free samples.

OTOH, the smaller devices are only $2-$4 each and are great for glue logic. The part manufactures also give out free software for the smaller devices.

Nice one,
David.

[mikewu99]

You can do quite a lot with the smaller Xilinx FPGAs (smaller Spartan 2 and Virtex series), they run around $25-$75 at Digikey. The development software for the smaller FPGAs is free (Xilinx WEBpack). It helps a lot if you know (or learn) Verilog or VHDL for design input.

Dumb newbie question:

Instead of removing jitter from a clock generated by the transport, why not modify the transport so that its output bit rate is synchronized to the DAC clock? A modest FIFO between the transport and the DAC, plus a rock-solid clock at the DAC and the jitter out of the transport would be irrelevent. The bit rate of the transport only has to be servoed to keep the FIFO from over/underflowing. Am I missing something here?