The best linear regulators have far faster response times than any switcher. This is something to be very careful about - the primary advantages of switchers are in efficiency, cost, and saved space. Micrel amongst others makes linears with far lower output noise, lower source impedance and much tighter output voltage tolerances for step changes in loads.
The only "demanding" rail in this project is the Vccint, though I suspect the 3A spec gives a pretty large safety factor for the speed/utilization of this project. Normally I'd recommend a switcher, but since this is DIY audio... Low-voltage, high-amperage transformers are pretty affordable. It feels a bit silly to feed a FPGA core with a transformer/linear supply, but eh, why not.
Update :
- All the hardware works (JTAG problems were actually the JTAG dongle's fault)
- Only hardware problem with the board so far is a pinout error on the LAN connector (the LED was reversed, lol)
- Ethernet driver is done about 50%, it's receiving ping packets from the PC but not sending yet.
This LAN chip is much easier to use than the 91c111. I like it.
- All the hardware works (JTAG problems were actually the JTAG dongle's fault)
- Only hardware problem with the board so far is a pinout error on the LAN connector (the LED was reversed, lol)
- Ethernet driver is done about 50%, it's receiving ping packets from the PC but not sending yet.
This LAN chip is much easier to use than the 91c111. I like it.
An externally hosted image should be here but it was not working when we last tested it.
Receiving UDP packets works @ 100 Mbps with no problems thanks to a little bit of custom DMA.
Now I will write the code to send packets.
The purpose of this board was to validate the FPGA design and the LAN9117, and I think it's going to be a success. SDRAM bandwidth is a bit on the low side, though, I shoulda put some DDR, but it will do.
But Spartan-3E 500 is a bit tight, it's 75% full now with the system, and the audio output module isn't done yet. I think it will fit, but implementing multichannel custom oversampling filters would need a larger FPGA.
Andrew, can you send me a PM ?
Now I will write the code to send packets.
The purpose of this board was to validate the FPGA design and the LAN9117, and I think it's going to be a success. SDRAM bandwidth is a bit on the low side, though, I shoulda put some DDR, but it will do.
But Spartan-3E 500 is a bit tight, it's 75% full now with the system, and the audio output module isn't done yet. I think it will fit, but implementing multichannel custom oversampling filters would need a larger FPGA.
Andrew, can you send me a PM ?
hi,all
I have developed a 24bit DAC with a FPGA in it.
the D/A are two PCM1794,running in MONO mode.differential output.
It has its own clock generator based on DDS technology(AD9852),and controled by FPGA,the Receiver IC is DIR9001.
The local DDS clock generator follow LRCK demoduate by DIR9001.
Now,I'm going to try FIR filter with different step and coefficient .
I have developed a 24bit DAC with a FPGA in it.
the D/A are two PCM1794,running in MONO mode.differential output.
It has its own clock generator based on DDS technology(AD9852),and controled by FPGA,the Receiver IC is DIR9001.
The local DDS clock generator follow LRCK demoduate by DIR9001.
Now,I'm going to try FIR filter with different step and coefficient .
Attachments
Peufeu, you're mad xD
The funny thing is that, like you, I'm building my dac with interconnecting cards - to put the dev a step further easily.
So what connectors have you choosen and on which edges?
Mines will be 90° edge, mini sub-d 15 (power regulators, i2s/pcm/DSD inputs), headers (reset/lock/mute/pullups/adress/i2c), sub-d 35 (8ch outputs). But I still can switch it
The funny thing is that, like you, I'm building my dac with interconnecting cards - to put the dev a step further easily.
So what connectors have you choosen and on which edges?
Mines will be 90° edge, mini sub-d 15 (power regulators, i2s/pcm/DSD inputs), headers (reset/lock/mute/pullups/adress/i2c), sub-d 35 (8ch outputs). But I still can switch it
Between the FPGA/Dice board and other boards, probably flat flex, those are good at high frequencies. This also gives freedom for the layout, and how to put the boards inside the box. Since the FPGA will have lots of IO, I'll put a flat flex connector with enough pins to control a multichannel DAC, and several other flat flex connectors with the remaining IO pins for other applications; like DSP, User interface, etc, or more channels, who knows.
Either we'll use the DICE's ARM cpu for everything (including handling ethernet packets) or it will have DICE+Microblaze, I'll know this when I try hooking both of those together !
Between the DAC, IV, and other analog modules (like LDR volume control for instance) I like this :
Those are cheap, use little space, make good contacts, and you get the number of pins you want. By connecting all the bottom pins to ground, you get good ground plane continuity.
Either we'll use the DICE's ARM cpu for everything (including handling ethernet packets) or it will have DICE+Microblaze, I'll know this when I try hooking both of those together !
Between the DAC, IV, and other analog modules (like LDR volume control for instance) I like this :
An externally hosted image should be here but it was not working when we last tested it.
Those are cheap, use little space, make good contacts, and you get the number of pins you want. By connecting all the bottom pins to ground, you get good ground plane continuity.
Peufeu,
I'm researching about TC Dice platform (Mini, Jr and II) and all I hear is horror stories from end-users. Particularly scary stuff is coming from gearslutz.com guys - clicks, frequent CPU spikes, dropouts, only TI 1394 chipsets that are working OK with Dice, etc.... Apparently Dice chips and consequently every firewire audio interface out there that has Dice in it are like a bad virus that everyone is trying to stay away from...
What is your take on it? Have you experienced any difficulties with using Dice chips? Do you think it may be an issue of (mass) improper implementation of drivers/firmware on designers' part?
I'm wondering if this platform (unfortunately pretty much the only one available with these features) is suitable for developing a solid pro-audio AD/DA firewire interface... CPU spikes is what worries me most...
Some links:
http://www.gearslutz.com/board/1602450-post6.html
PS: Could you elaborate on your source for Dice chips?
PPS: How is the progress on your DAC project?
I'm researching about TC Dice platform (Mini, Jr and II) and all I hear is horror stories from end-users. Particularly scary stuff is coming from gearslutz.com guys - clicks, frequent CPU spikes, dropouts, only TI 1394 chipsets that are working OK with Dice, etc.... Apparently Dice chips and consequently every firewire audio interface out there that has Dice in it are like a bad virus that everyone is trying to stay away from...
What is your take on it? Have you experienced any difficulties with using Dice chips? Do you think it may be an issue of (mass) improper implementation of drivers/firmware on designers' part?
I'm wondering if this platform (unfortunately pretty much the only one available with these features) is suitable for developing a solid pro-audio AD/DA firewire interface... CPU spikes is what worries me most...
Some links:
http://www.gearslutz.com/board/1602450-post6.html
PS: Could you elaborate on your source for Dice chips?
PPS: How is the progress on your DAC project?
Are there any options comparable to Dice in functionality though? I want to be able to stream at the very least 8 channels in and 8 channels out at 192Khz with <1ms latency (which is what Dice does). I don't know much about programming FPGAs, therefore I can't do anything similar to Dice by myself.
Options like CobraNet won't do it for me. Everything else seems worse than Dice in terms of NDA, licensing, etc... (SuperMAC, EtherSound, Dante, BridgeCo)...
Options like CobraNet won't do it for me. Everything else seems worse than Dice in terms of NDA, licensing, etc... (SuperMAC, EtherSound, Dante, BridgeCo)...
If you think that @192Khz it has 1ms latency, then at @44.1Khz it would have ~4ms - that's on the verge of becoming unacceptable for proaudio use. Count in other small delays + host drivers - you're looking at 5-6ms latency, that's too much.
Sure I would love to use these things for stage performances. =) but that calls for rock solid drivers, which there are very very few of right now (RME comes to mind)...
USB (so I heard) has inherently worse jitter specs - that's why it's not as widely used for audio as Firewire (besides purely marketing reasons and pushes from Apple and co.). There is no chip that I know of that has optimization for audio streams to bring it up to compete with Firewire in that regard. But then, smart implementation might fix this issue...
What ever happened to the Oxford Semi 971 chip? It's easier to find real spy pictures of naked presidents than to source that chip... I'm amazed there is nothing out there for a small-medium scale company (not even mentioning DIY) to use for development of proaudio 1394 interfaces... I've heard there is also Echo Audio firewire solution, but there is pretty much zero info on this on the web.
BridgeCo - $$$
TC Dice - $$$$
TI chip - too consumer
Echo Audio - ??
Oxford - ???
Bad scenario...
PS: But now I know what I will do if I win the lottery =) Hire smart people (like you guys on this forum) to design a kick-*** ASIC that will do 128 channel i/o over Firewire-800 with open source Firmware etc.. =) Oh, and not to mention sold IN SINGLE quantities to ANYONE for under $20... How does that sound? =)
Sure I would love to use these things for stage performances. =) but that calls for rock solid drivers, which there are very very few of right now (RME comes to mind)...
USB (so I heard) has inherently worse jitter specs - that's why it's not as widely used for audio as Firewire (besides purely marketing reasons and pushes from Apple and co.). There is no chip that I know of that has optimization for audio streams to bring it up to compete with Firewire in that regard. But then, smart implementation might fix this issue...
What ever happened to the Oxford Semi 971 chip? It's easier to find real spy pictures of naked presidents than to source that chip... I'm amazed there is nothing out there for a small-medium scale company (not even mentioning DIY) to use for development of proaudio 1394 interfaces... I've heard there is also Echo Audio firewire solution, but there is pretty much zero info on this on the web.
BridgeCo - $$$
TC Dice - $$$$
TI chip - too consumer
Echo Audio - ??
Oxford - ???
Bad scenario...
PS: But now I know what I will do if I win the lottery =) Hire smart people (like you guys on this forum) to design a kick-*** ASIC that will do 128 channel i/o over Firewire-800 with open source Firmware etc.. =) Oh, and not to mention sold IN SINGLE quantities to ANYONE for under $20... How does that sound? =)
No need for ASICs, just get a FPGA, fire up a text editor and write a verilog IEEE1394 core... Far from trivial though.
FireWire has less jitter than USB because in FW the ticks are hardware generated, in USB they are a software IRQ. Also FW uses less CPU than USB.
However USB is much simpler and a bit more mature. FW devices need to be smart, and USB devices are dumb, hence, easier to implement.
The jitter specs only matter if you recover the audio clock from the bus, which I absolutely don't intend to do. With the clock in the device, this problem disappears.
Oxford Semi... I only see HDD controllers from them ?...
FireWire has less jitter than USB because in FW the ticks are hardware generated, in USB they are a software IRQ. Also FW uses less CPU than USB.
However USB is much simpler and a bit more mature. FW devices need to be smart, and USB devices are dumb, hence, easier to implement.
The jitter specs only matter if you recover the audio clock from the bus, which I absolutely don't intend to do. With the clock in the device, this problem disappears.
Oxford Semi... I only see HDD controllers from them ?...
Take a look at the attached datasheet. That's about all I could find about this neat chip. Other than it is being used in Apogee FW interfaces (Duet / Ensemble) and some others...
Is it possible to replicate the same exact functionality (minus the ARM7) using an off the shelf FPGA? Can the performance be matched?
Just found a more in-depth datasheet on OXFW971 -
http://dev.ax-design.com/electronics/OXFW971_DS.pdf
Also, according to THIS POST , the chip is phased out... To be replaced with what?...
http://dev.ax-design.com/electronics/OXFW971_DS.pdf
Also, according to THIS POST , the chip is phased out... To be replaced with what?...
peufeu said:Multichannel is a requirement for me.
It will be either USB2 or Ethernet. In the end I think I like USB2.
Why would you want 1 ms latency ? Unless you want to use it for live performances ? (well if your nick is promixe I'd guess that
Why have you choose to go with USB2?
Reading other posting from you i thought the choice was Ethernet.
Ciao
Andrea
Ethernet is nice (especially for isolation) but it means the device must contain a powerful CPU to handle the data packets, which adds complication and prevents the use of free tools (XPS or Nios license or adding a hard ARM which adds cost and complexity). USB is much simpler as all the software is in the PC. USB also has more bandwidth.
In the end since it should behave as a real soundcard a driver will have to be written, which is simpler for USB also.
In the end since it should behave as a real soundcard a driver will have to be written, which is simpler for USB also.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.