[sdiy] Generating a large number of CV outputs

[brianw]

A big consideration is the many aspects of how the CPU interfaces with the DAC, as well as how the DAC handles the data conversion.

One variable is fixed versus variable sample rate. With a fixed sample rate, your CPU has to generate data transfers continuously, even though the value may not actually be changing. This can be a benefit if your S/H circuit needs refreshing to keep the capacitors from drooping in voltage over long periods, but there are other ways to solve that. With a DAC that can handle variable sample rates, e.g., a DAC that will only update the output voltage when you tell it to, the CPU does not have to generate data unless there is a change. If your primary focus is responding to MIDI Continuous Control change messages, then it's much easier to design with a DAC will will accept a new value as soon as a message comes in, rather than a DAC that needs a continuous data stream (usually fed from a waveform buffer). DAC chips that operate on a fixed sample rate require a clock signal as part of the serial bus that they use, whereas DAC chips that are flexible about fixed or variable sample rate do not need a clock, per se, because they have a "convert" signal to load each new value. There is clearly some overlap in the design here, but the point is that you want to think about what the CPU is required to do to feed the DAC. In general, a DAC that is capable of variable sample rates will hold a DC value between changes, whereas (in general) many audio DAC chips require a fixed sample rate with large words and do not guarantee DC.

Another variable is the interface: parallel versus serial. This can be important because some modern CPU chips are very limited in number of GPIO pins. This can be solved with an external serial-to-parallel chip, but that's an extra part. Related to sample rate above, parallel interfaces can generally be updated at any rate, whereas serial interfaces often require a fixed sample rate. That said, there are certainly serial interface converter chips that will operate with variable sample rates, but their serial interface protocol needs at least an extra bit to start and stop each asynchronous transfer. The fixed sample rate serial interfaces generally have a clock, word select, and data lines.

A huge issue is whether the DAC employs oversampling, and thus whether it can handle multiplexing unrelated signals through a MUX. In general, a parallel interface DAC does not employ oversampling, and thus you can feed lots of unrelated signals through the DAC without concern about "crosstalk" due to the oversampling filters blending subsequent sample values together. All 24-bit audio CODEC chips use oversampling filters such that the output at any time is influenced by the last several values. This makes an audio CODEC chip inappropriate for use with a S/H MUX. I've heard people argue that you can determine the impulse response of your CODEC, and feed in extra 'zero-value' samples to clear the filter state between each conversion, and supposedly this will allow unrelated signals to be passed through the CODEC without each signal interfering with the other. But that's an example of way too many bits in each word and way too many data transfers per conversion to be an efficient model. Your CPU will run out of power an order of magnitude faster with this approach.


To use specific examples:

If you pick an 8-channel audio CODEC that's capable of 44.1 kHz to 192 kHz, then your CPU will need DMA buffers in memory with 24-bit waveform data for all 8 channels, and a serial digital audio interface with clock, data, word and channel control signals running constantly. Changing the output value for one channel requires knowing what point in the DMA cycle a given channel is so that you can update the waveform memory without unexpected glitches. You're also stuck with that same fixed sample rate for all 8 channels. The CODEC option does not allow for a (reasonable) MUX expansion beyond the supported 8 channels. More channels means more serial interfaces, and the CPU will have a limited number of serial digital audio interfaces.

If you pick a 1-channel precision DAC that's capable of 125 MHz at 14-bit or 16-bit, combined with a control signal to trigger the conversion, then your CPU will only need to transfer data as needed. You also have the option of fixed sample rate here, but it's not required. Individual S/H outputs can be updated at any rate you desire, so long as the overhead of the MUX address and S/H timing is handled (preferably by hardware logic) quickly enough to support the desired sample rate. This sort of design even allows different sample rates for different outputs, although you can't guarantee simultaneous update of multiple outputs without a second stage of S/H. You can run as many channels as you like, provided you have a large enough MUX with S/H stages.


I've designed a 32-channel system using a 14-bit current output DAC that is capable of 125 MHz. It's fed by a DMA triggered at 4 MHz, spanning all 32 channels, so each channel has an update rate of 125 kHz. In this case, I was generating waveforms, so it made sense to use DMA and prepare the waveform data in memory.

I've also designed a 16-channel system using a 16-bit voltage output DAC with a rate that's not quite as high as the current output DAC. This system is for CV, and I haven't decided whether to use a fixed sample rate or a variable sample rate, but the key is that the hardware and interface do not force the choice.


Personally, given the long history of DAC and CODEC designs, I strongly recommend against designing your own converter. These filtered pulse solutions have much longer settling times than the 8-nanosecond setting time of that 125 MHz current output DAC (from Texas Instruments).

Brian Willoughby

p.s. One or more folks have suggested spreading out the MUX S/H channels across different areas of the PCB. There's a hidden advantage here because if you try to put all of the S/H MUX channels in a central location, then you have the challenging of maintaining an accurate analog voltage (ground) reference over a large area. If, instead, you spread the channels across multiple smaller areas (even separate PCBs!) and use digital connections between board areas, then a smaller number of channels can be handled by a DAC that shares an analog ground reference with the CV signals in that area. You're more likely to achieve 16-bit accuracy if you design the analog references more carefully, especially keeping them local.


On Dec 7, 2023, at 4:35 PM, Danjel van Tijn / intellijel <danjel at intellijel.com> wrote:
> What is the current ideal way to generate a large number of CV outputs from a single CPU?
> 
> Let's say I wanted to generate 100 outputs with an update rate of a few kHz and an equivalent bit depth of 12 or 16 bits.
> 
> I know that back in the day when DACs were extremely expensive, the designs would use a single DAC and then demux to a bunch of S&Hs.  
> 
> Now that DACs are cheaper, is it better to chain a bunch of 8- or 16-channel DACs? 
> 
> Or would it make more sense to use an FPGA and create a giant multi-channel 1-Bit DAC?
> 
> Looking at some Elektron hardware teardowns it appears that they are using the latter approach.