The point being, that the ADCs don't need PLLs at all. The bit/word clocks keep the samples synchronized. The master clock doesn't really need to be synchronized. He's only got 40-50 channels. I can do 48 channels in three (six is a little cheaper) DACs and no more than six ADCs. That's not a huge footprint to route a couple of 12.288MHz clocks around, if you insist on synchronizing master clocks.
That's easy. As long as you can generate the data coherently, delivering it to DACs is a piece of cake. A sample time is forever.
[...]
Yup, looks like it :-(
[...]
Sure, but then things become quite expensive if you want 18 bits or more. Sound codecs have the mass market advantage when it comes to pricing.
-- Regards, Joerg http://www.analogconsultants.com/
[...]
I am not concerned about DACs but about ADCs. There is a massive amount of data. Could be handled by modern USB if there'd be chips and drivers.
-- Regards, Joerg http://www.analogconsultants.com/
Nah. >110dB dynamic range differential output DACs are cheap. We pay something under a buck a piece for 8-channel DACs. Our quantities are higher than you're likely to see, though. ;-) At 1K volumes, they're probably three or four bucks.
It's the same problem, but backwards. ;-) Synchronization isn't the problem. You don't have *that* many channels.
What are your latency requirements ?
While that number of channels and SNR requirements, should be doable with a PCI card inside a computer, but for more demanding requirements, I would look at some external ADC board(s), which would simplify (balanced) signal conditioning, EMC issues and galvanic isolation issues.
With an external board with say 8 channels and an ethernet interface might be an alternative.
With three bytes/sample that would generate 24 bytes/sample. With two samples/frame this would nicely fill the minimum size ethernet frame. With a few more samples/frame and the bit efficiency would be even better, allowing several such eight channel units even through a single 100BaseT ethernet port on the host. Larger systems or higher sampling rates would require a 1000BaseT connection between the ethernet switch and the host computer, while the ADC board to switch connections could still be 100BaseT.
To synchronize the sample clocks on different ADC units, some NTP style system could be used.
Again, it's about ADCs here. DACs are a piece of cake.
-- Regards, Joerg http://www.analogconsultants.com/
Well, I will have that many channels. I am just looking for a possible cheapo solution using sound chips. If there is no viable one then I'll do it the classic way. BTDT, the most massive one had 64 ADCs.
-- Regards, Joerg http://www.analogconsultants.com/
Latency does not matter, provided it is exactly the same for all ADC channels or (if not) the data is time-stamped.
They are usually prohibitively expensive.
Yes, but at lab equipment pricing levels :-)
I'd rather go in via PCI or USB, it is probably simpler and we could likely pull a lot from FPGA vendor libraries.
-- Regards, Joerg http://www.analogconsultants.com/
ADCs are just backwards DACs. They're a bit more expensive but still cheap, though I don't know of any 8-channel ones. I use four-channel ADCs (106dB) all the time, though. Audio stuff is really cheap.
You said forty or fifty. That's not many, when they come four and eight to the whack. Even 64 isn't that large. Synchronization is
*NOT* your problem. That's the easy part.
Audio yes, regular ADCs no. I just needed one for a design and 12-bit
1-ch at 100ksps is already above a buck. If you want 18-bits or better anything other than audio is really expensive. DACs are cheap, ADCs aren't.-- Regards, Joerg http://www.analogconsultants.com/
In this case it's 40-50, the 64-ch version was a project way back when and that one had a BW north of 25MHz. Sync for that was not cheap.
I was hoping for something easy like a special big fat USB hub or something. But I guess it either has to be ADAT or roll-our-own.
-- Regards, Joerg http://www.analogconsultants.com/
But you just said you needed to digitize audio. Are you moving the goal posts?
No. I wanted to know how to line up umpteen audio codecs in a way that they talk to a PC and remain 100% synchronous. Using ADCs for otyher markets is expensive.
-- Regards, Joerg http://www.analogconsultants.com/
I guess the subject and other posts in the thread just confused me. ;-)
You did not say anything about expected production volumes (just a one off project or thousands of units) and hence is it feasible to design your own PCI card.
If you have to design your own PCI card, what is wrong with the old stereo audio ADCs such as the CS5394, apart from the board space needed for 10+ stereo ADC chips ?
It has differential inputs, a 2 Hz audio high pass (so no DC
slave mode, put one in master mode and the rest in slave mode and tie all the clock signals together.
signals to something usable for a computer, such as 32 bit parallel words/sample to presented to the PCI bridge chip.
If some serial interface such as Ethernet, USB or PCIe is used, then put the sample from every channel into the same frame (preferably 32 bits/sample to simplify CPU load), thus all samples from a particular time would be guarantied to be available in the same frame.
Then you will have to think how you will get the data from the PC interface card into memory, perhaps DMA or interrupt driven. However, if every sample will generate an interrupt, there would be 40000 interrupts each second at 40 kHz sampling rate, which is quite a lot. Transferring 40 samples for each interrupt would give 1000 interrupts/second, which is a reasonable value.
If the data is to be processed with some soft-RT system, such as Windows or Linux, you may still need quite a lot of software FIFO buffering between the ISR and user mode code.
So it is not just the ADC interface you need to consider but also other parts of the system, in order to avoid making some local optimizing that greatly harms the rest of the system.
Yep. I'd use something larger than stereo and some version or TDM, rather than I2S but that's just details. I'd need to know more about the application before diving too far into the details.
Precisely. You could pull the PCI bridge into the FPGA but I'd probably go the easy way, too. The PLX bridges were a piece of cake to use. That was a *long* time ago, though. ;-)
Sure, but it's not a big deal to buffer them, either. You just need to make sure that the buffers can be kept full. Like I said, synchronizing the hardware is the easy part.
Sure. Again, I'd buffer the samples at the bridge to keep the interrupts under control.
Do it in hardware, at the I2S/TDM controller. Dual-port memory on FPGAs is pretty cheap (once you've bought into an FPGA).
Yep. The hardware is the easy part. ;-)
Initially in the hundreds/year but must have a chance to become a high-vlumen product without major architectural changes.
Nothing wrong with that. I was simply wondering if there'd be any simpler and more contemporary method, for example via USB. This is how SDR is done, with huge data streams.
Yes. I know pretty much how to do it, was just wondering if there is an alternative to a brute force FPGA approach.
Yeah, writing our own driver, that will be a major bear and this is at least half the reason why I asked for an already existing "off-the-shelf" method. And maybe with ADAT there is one. Although somewhat limited as well, AFAIK even the high channel number Focusrite Safire interface is restricted to 16 audio channels into the PC. But ... this could be an avenue with less engineering effort than a card with a big old FPGA on there and having to write our own driver.
-- Regards, Joerg http://www.analogconsultants.com/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.