Given what you want, you might find it hard to persuade those with the necessary skills that such functions are not better or at least more easily done on a PC and that may prove to be your biggest hurdle. Observation would suggest things tend to get done by those with the ability and the drive and the desire to see it through. IME if you want someone to do something they are not all that interested in, you have to pay them.
rfbrw said:
I'm not sure if that was directed to me, but what I want is not that easy to achieve using a PC. Sure, the software can be written, but how would you output 8 channels from a PC? Wouldn't you need to buy an audio card? That's not my definition of DIY.
The basic DEQX system is ~$3000. I looked into alternatives. There are no good solutions currently available that are cheaper than that. I would think there are quite a number of DIYers and audiophiles who would like this solution. I've seen many posts and threads discussing digital room correction, filtering, etc. Anyway, you're essentially right. If there isn't the interest, it won't happen.
A mini fanless PC with a decent processor and DDR ram : $500
DIY measurement microphone with preamp : $20
Linux, BruteFIR, Octave : $0
RME soundcard with 8 digital in/out : $300
For active crossover you can't beat brutefir. Custom DSP hardware with custom DSP algorithms would be a better choice if you make a few tens of thousands of units and the cost of the man-year of highly qualified engineer time for developing said DSP hardware and software can be amortized (because a DSP costs $1 and a PC costs more than that !) ; but for a DIY project you'll need a PC unless you are already an expert in DSP programming...
Now for the question of data transfer, you have a problem, and that problem is spdf...
8 channels of audio isn't that large a bandwidth, so a PCI audio card with onboard dacs will have no problems. However there are no audiophile soundcards.
The other solution is to use the spdif or adat outputs on a specialized soundcard like RME and an outside DAC. It can work well.
As I'm writing this message, the xilinx tools are trying to stuff my verilog code into a FPGA on a little board with an ethernet socket on one end and a lot of I/O pins on the other end. Guess what I'm gonna do with this
DIY measurement microphone with preamp : $20
Linux, BruteFIR, Octave : $0
RME soundcard with 8 digital in/out : $300
For active crossover you can't beat brutefir. Custom DSP hardware with custom DSP algorithms would be a better choice if you make a few tens of thousands of units and the cost of the man-year of highly qualified engineer time for developing said DSP hardware and software can be amortized (because a DSP costs $1 and a PC costs more than that !) ; but for a DIY project you'll need a PC unless you are already an expert in DSP programming...
Now for the question of data transfer, you have a problem, and that problem is spdf...
8 channels of audio isn't that large a bandwidth, so a PCI audio card with onboard dacs will have no problems. However there are no audiophile soundcards.
The other solution is to use the spdif or adat outputs on a specialized soundcard like RME and an outside DAC. It can work well.
As I'm writing this message, the xilinx tools are trying to stuff my verilog code into a FPGA on a little board with an ethernet socket on one end and a lot of I/O pins on the other end. Guess what I'm gonna do with this
This is really interesting. If my guess is right you are trying to do multi channel digital audio over ethernet, the FPGA receive it, split the channels, do some processing (DLL reclocking, FIFO buffer, FIR fliters) and map N i2s channels on output pin to convert them with N DAC.
This is exactly what i have on my mind, when i have the time to do some experiments with my FPGA development board i will let you know.
Ciao
Andrea
Yeah, except the PC will be doing the crossover, not the FPGA (I won't reimplement BruteFIR, it just works so well).
I learnt verilog last week
Right now the board is receiving UPD packets and has no problems coping with the full 100 Mbps bandwidth. That makes quite a few channels...
I'm just a few software and verilog bugs away from a ring buffer in sdram, and then implementing I2S in the FPGA should be easy.
ezkcdude said:
For dev boards
http://www.digilentinc.com/
for info and open ip cores
http://www.opencores.com/
and this to learn VHDL
http://tams-www.informatik.uni-hamburg.de/vhdl/doc/cookbook/VHDL-Cookbook.pdf
Ciao
Andrea
peufeu said:
Yeah, except the PC will be doing the crossover, not the FPGA (I won't reimplement BruteFIR, it just works so well).
I learnt verilog last week
Right now the board is receiving UPD packets and has no problems coping with the full 100 Mbps bandwidth. That makes quite a few channels...
I'm just a few software and verilog bugs away from a ring buffer in sdram, and then implementing I2S in the FPGA should be easy.
OK for brutefir choice.
I use VHDL and the free dev framework from xilinx.
For i2s you can use this
http://www.opencores.com/projects.cgi/web/i2s_interface/overview
Ciao
Andrea
damn damn damn
for some reason (maybe the reason is this is my first project) I'm running into hardware timing bugs, because the board I use (Suzaku) has the SDRAM and the MAC chip on the same bus and I must multiplex all this, and the multiplexing time drops a few precious nanoseconds !
I also have a nagging software bug where the ethernet stops raising interrupts after a few million packets received.
That's really nasty to debug...
for some reason (maybe the reason is this is my first project) I'm running into hardware timing bugs, because the board I use (Suzaku) has the SDRAM and the MAC chip on the same bus and I must multiplex all this, and the multiplexing time drops a few precious nanoseconds !
I also have a nagging software bug where the ethernet stops raising interrupts after a few million packets received.
That's really nasty to debug...
Hehe ; I can use gdb to debug my embedded processor via JTAG... set breakpoints and watch variables as if it was running locally.
Bug squashed.
Those FPGA synthesis tools sure are slow. It takes something like 10 minutes to synthetize after changing a damn state machine. I need a dual dual core duo !
And I got my nanoseconds back too !
cool.
Bug squashed.
Those FPGA synthesis tools sure are slow. It takes something like 10 minutes to synthetize after changing a damn state machine. I need a dual dual core duo !
And I got my nanoseconds back too !
cool.
LOL.
Yeah I remember doing VHDL simulations on a SparcStation 1 when I took a VLSI class at school. That was awful.
Does anybody have the formula right for byte lane steering when reading data from a BRAM according to an incrementing counter ? my bytes are all reversed in some strange way, and I'm mixed between the VHDL and Verilog conventions (which are reversed) ; and the CPU seems to change endianness every time I synthetize XD
Yeah I remember doing VHDL simulations on a SparcStation 1 when I took a VLSI class at school. That was awful.
Does anybody have the formula right for byte lane steering when reading data from a BRAM according to an incrementing counter ? my bytes are all reversed in some strange way, and I'm mixed between the VHDL and Verilog conventions (which are reversed) ; and the CPU seems to change endianness every time I synthetize XD
Maybe another thread should be started on this subject, but...
What FPGA models and packages are good for DIYers? Which chips are you guys using and what is the programming environment? Also, has anyone tried using Matlab/Simulink to program these FPGA's? I'm a Matlab guy, so that would be a more comfortable way for me to get started. Thanks, in advance.
Edit: I'm looking at the Spartan 3E starter (#122-1501-ND) kit available at digikey for $149. Would that be a good thing for me to learn on?
What FPGA models and packages are good for DIYers? Which chips are you guys using and what is the programming environment? Also, has anyone tried using Matlab/Simulink to program these FPGA's? I'm a Matlab guy, so that would be a more comfortable way for me to get started. Thanks, in advance.
Edit: I'm looking at the Spartan 3E starter (#122-1501-ND) kit available at digikey for $149. Would that be a good thing for me to learn on?
I'm no expert on FPGA, actually this is my first project and I'm learning the hard way.
I'm creating a website for it.
In choosing a FPGA board you must keep this in mind :
- the embedded CPU is slow (25 mips)
- the OPB bus is only fast for burst accesses, which means your code should be in on-chip RAM
* connectivity ? USB or Ethernet ? I prefer Ethernet.
Consider how much bandwidth you need.
* storage ?
I mean you will want to buffer the packets to prevent dropouts. There are three types of memory :
- BRAM (SRAM embedded on the FPGA) : it's superfast, but small (48 kB in spartan 3 1M gate version), and you have to put your CPU code in it too. It's good for FIFOs though, because it's dual port (2 simultaneous accesses).
- External SRAM : fast and easy to use
- External SDRAM : fast only on burst accesses (1 clock/word), very slow on random accesses (~10 clocks/access)
The most important point is to evaluate how much throughput you need.
When the PC sends data to the card, it will not be at regular intervals. When the PC is loaded, doing a disk access for instance, it will stop transmitting for a few hundreds ms, then send the backlog of packets at max wire speed, and your tiny FIFO will overload.
Therefore you MUST be able to transfer data from the network interface to a large (SDRAM) buffer at a much higher rate than ethernet wire speed (preferrably double).
For ethernet you have two choices :
- the board has a MAC+PHY chip (SMC91c111 style) : easy to use but you really need an embedded microprocessor to drive it (like microblaze embedded in FPGA). The chip has an embedded FIFO of 8 kB.
- the board only has a PHY and you must use a MAC core in the FPGA. Xilinx will be happy to licence theirs to you for $15000, or you can use the free one from opencores.
In case 1, worst case (my board, Suzaku) is that there is a narrow 16-bit external bus which is shared between the SDRAM chip and the MAC chip.
With an embedded MAC and external SDRAM you can plug the SDRAM controller core direct to the SDRAM chip and transfers will be much faster.
I'm creating a website for it.
In choosing a FPGA board you must keep this in mind :
- the embedded CPU is slow (25 mips)
- the OPB bus is only fast for burst accesses, which means your code should be in on-chip RAM
* connectivity ? USB or Ethernet ? I prefer Ethernet.
Consider how much bandwidth you need.
* storage ?
I mean you will want to buffer the packets to prevent dropouts. There are three types of memory :
- BRAM (SRAM embedded on the FPGA) : it's superfast, but small (48 kB in spartan 3 1M gate version), and you have to put your CPU code in it too. It's good for FIFOs though, because it's dual port (2 simultaneous accesses).
- External SRAM : fast and easy to use
- External SDRAM : fast only on burst accesses (1 clock/word), very slow on random accesses (~10 clocks/access)
The most important point is to evaluate how much throughput you need.
When the PC sends data to the card, it will not be at regular intervals. When the PC is loaded, doing a disk access for instance, it will stop transmitting for a few hundreds ms, then send the backlog of packets at max wire speed, and your tiny FIFO will overload.
Therefore you MUST be able to transfer data from the network interface to a large (SDRAM) buffer at a much higher rate than ethernet wire speed (preferrably double).
For ethernet you have two choices :
- the board has a MAC+PHY chip (SMC91c111 style) : easy to use but you really need an embedded microprocessor to drive it (like microblaze embedded in FPGA). The chip has an embedded FIFO of 8 kB.
- the board only has a PHY and you must use a MAC core in the FPGA. Xilinx will be happy to licence theirs to you for $15000, or you can use the free one from opencores.
In case 1, worst case (my board, Suzaku) is that there is a narrow 16-bit external bus which is shared between the SDRAM chip and the MAC chip.
With an embedded MAC and external SDRAM you can plug the SDRAM controller core direct to the SDRAM chip and transfers will be much faster.
Finally I got the last bug.
It does 100 Mbps full duplex with about 30% spare CPU (the PC sends a stream of UDP packets, the board reads them, buffers them in BRAM and sends them back to the PC).
Since I plan to have multichannel audio from PC to DAC I need good bandwidth ; the other way around I'll have only 2 channels of ADC and synchronization data so I'll use only a fraction of the bandwidth.
Using raw ethernet packets is easier on the device side but harder on the PC side, that's why I chose UDP. Right now the board responds to ARP and parses UDP, that's all I need.
Stuff like autonegociation etc, works.
Next is the SDRAM buffer. This should be a lot easier as the Xilinx lib already includes pretty good SDRAM and DMA controllers, which I have already added to the design and tested, along with the proper bus mux.
I feel I'm past the bump
NB: This card does 160-200 kbytes/s max on tcp/ip transfers if you run uclinux on the factory default configuration.
I use no OS. This thing is much too underpowered to allow for such fancy stuff. I have gutted the linux driver for my chip and extracted only the juicy parts.
It does 100 Mbps full duplex with about 30% spare CPU (the PC sends a stream of UDP packets, the board reads them, buffers them in BRAM and sends them back to the PC).
Since I plan to have multichannel audio from PC to DAC I need good bandwidth ; the other way around I'll have only 2 channels of ADC and synchronization data so I'll use only a fraction of the bandwidth.
Using raw ethernet packets is easier on the device side but harder on the PC side, that's why I chose UDP. Right now the board responds to ARP and parses UDP, that's all I need.
Stuff like autonegociation etc, works.
Next is the SDRAM buffer. This should be a lot easier as the Xilinx lib already includes pretty good SDRAM and DMA controllers, which I have already added to the design and tested, along with the proper bus mux.
I feel I'm past the bump
NB: This card does 160-200 kbytes/s max on tcp/ip transfers if you run uclinux on the factory default configuration.
I use no OS. This thing is much too underpowered to allow for such fancy stuff. I have gutted the linux driver for my chip and extracted only the juicy parts.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.