FPGA?
Hello All-
I am currently working on some FPGA audio-related things for a pro-audio system I am designing (does multi-track recording). I wanted to share a little about designing with FPGAs in general that I have found out:
1.) The vendor tools are not so easy to use, just the installation on your PC often requires gigabytes of patches and updates straight away. These have improved quite a lot, but they have a long way to go before they are as easy to run as Mentor Graphics PADS or AutoCAD.
2.) If you are a C or assembly language programmer, I think you'll be able to write VHDL or Verilog pretty easily, but get ready for a pile of "gotchas" when you go to compile your code! Getting your input to output pin timing constraints handled will use up more than 50% of your development time, I'll bet.
3.) Large gate-count FPGA devices often require a real software license to be programmed by the vendor's software tools. I think this is because you WILL need their help to get your design to actually work, and no one likes to work for "free" I have found.
4.) If you don't have a lot of very high-speed PC board design under your belt (I don't, as a matter of fact), get ready to learn a LOT from the layout errors you will undoubtedly commit. Many FPGA I/O pins can easily have 250MHz signals on them, but perhaps this isn't really applicable to your project, I guess. Just making reference to some of my personal issues I have encountered!
5.) Make sure you REALLY will benefit from using a FPGA before you design a board around it. There are a lot of "extras" that are needed, like a flash SRAM for storing your FPGA config in (most FPGAs are non-volatile memory, when the power goes so do the bits). Many designers end up using a ARM or PIC micro just to program the FPGA chip on startup!
From looking at your basic design sketch, maybe a hybrid uP device like a Analog Devices "BlackFin" might be the easiest to work with and program? The Spartan 3E-500 you were discussing does come in a smaller package than the FG320 or FG400 (320 and 400 pins respectively), you can get it down to a CP132 (Chip Scale BGA, 132 pins). From what I have read, this is the smallest gate-count device that you can probably get the MicroBlaze core to even build in. The Xilinx development kit for this soft-processor is built with a 1.6 million gate Spartan 3E device.
Just my two cents, if you're already past this stage and successful, carry on and enjoy!!!
Hello All-
I am currently working on some FPGA audio-related things for a pro-audio system I am designing (does multi-track recording). I wanted to share a little about designing with FPGAs in general that I have found out:
1.) The vendor tools are not so easy to use, just the installation on your PC often requires gigabytes of patches and updates straight away. These have improved quite a lot, but they have a long way to go before they are as easy to run as Mentor Graphics PADS or AutoCAD.
2.) If you are a C or assembly language programmer, I think you'll be able to write VHDL or Verilog pretty easily, but get ready for a pile of "gotchas" when you go to compile your code! Getting your input to output pin timing constraints handled will use up more than 50% of your development time, I'll bet.
3.) Large gate-count FPGA devices often require a real software license to be programmed by the vendor's software tools. I think this is because you WILL need their help to get your design to actually work, and no one likes to work for "free" I have found.
4.) If you don't have a lot of very high-speed PC board design under your belt (I don't, as a matter of fact), get ready to learn a LOT from the layout errors you will undoubtedly commit. Many FPGA I/O pins can easily have 250MHz signals on them, but perhaps this isn't really applicable to your project, I guess. Just making reference to some of my personal issues I have encountered!
5.) Make sure you REALLY will benefit from using a FPGA before you design a board around it. There are a lot of "extras" that are needed, like a flash SRAM for storing your FPGA config in (most FPGAs are non-volatile memory, when the power goes so do the bits). Many designers end up using a ARM or PIC micro just to program the FPGA chip on startup!
From looking at your basic design sketch, maybe a hybrid uP device like a Analog Devices "BlackFin" might be the easiest to work with and program? The Spartan 3E-500 you were discussing does come in a smaller package than the FG320 or FG400 (320 and 400 pins respectively), you can get it down to a CP132 (Chip Scale BGA, 132 pins). From what I have read, this is the smallest gate-count device that you can probably get the MicroBlaze core to even build in. The Xilinx development kit for this soft-processor is built with a 1.6 million gate Spartan 3E device.
Just my two cents, if you're already past this stage and successful, carry on and enjoy!!!
Re: FPGA?
I don't think that's an issue... we're not using the clock from that SPDIF anyway. It's only 5 cm of trace on ground plane... and not connecting to the ground plane would make the transmission line longer since the RXN goes to 3 SPDIF inputs.
Resistors are there, some of them are on Toplevel.sch due to some net naming issues...
Yes, Xilinx XPS is quite a bloatware and not that user-friendly, but once you get it it gets the job done quite well.
Yes for Virtex-4 and 5, no for Spartan (all models work with the free tools)...
Yeah, me neither, I'm trying to learn...
Actually Spartan-3E can configure itself from an Atmel DataFlash. I also include a Xilinx Platform Flash which is programmable via JTAG.
Actually the entire system for ethernet audio streaming with microblaze and peripherals builds in a 3E500 and there is still space left, EXCEPT there isn't enough BRAM so it wouldn't work. For this test platform it will be cool.
I know
Yeah, I know about this new breed of chips, they're quite interesting (although you can't do everything with biquads) however I'd like to try other stuff like doing the oversampling in the FPGA etc... I dunno if I will write a FIR core or use the one from Xilinx, either way it shouldn't be too hard.
What's done :
- Clock & reclock module : schematics OK, missing power supplies. Includes an I2C DAC to control a VCXO. Or just don't solder it and use a normal XO.
- Clock -> DAC connector : pinouts done
- DAC -> Analog module (IV or Output) connector : pinouts done
- DAC -> PSU connector : pinouts done
- Ethernet-less simple FPGA module to test my design before committing to BGA and an expensive PCB : schematics done
I had to re-read all DAC datasheets to be sure not to miss anything in the connectors. That was long.
Next step is to finish my N2PK vector network analyzer that has been waiting for too long and test some decoupling schemes and regulators.
I will also need a low noise amplifier to test for regulator noise with my soundcard. Ideas ?
Meanwhile I can also advance on the schematics for a few more modules. First DAC will be the AK4396 since I have one, and it's voltage out so no need for IV.
See ya
kevinkr said:
I don't think that's an issue... we're not using the clock from that SPDIF anyway. It's only 5 cm of trace on ground plane... and not connecting to the ground plane would make the transmission line longer since the RXN goes to 3 SPDIF inputs.
Resistors are there, some of them are on Toplevel.sch due to some net naming issues...
Cliff45 said:
Yes, Xilinx XPS is quite a bloatware and not that user-friendly, but once you get it it gets the job done quite well.
3.) Large gate-count FPGA devices often require a real software license to be programmed by the vendor's software tools. I think this is because you WILL need their help to get your design to actually work, and no one likes to work for "free" I have found.
Yes for Virtex-4 and 5, no for Spartan (all models work with the free tools)...
Yeah, me neither, I'm trying to learn...
Actually Spartan-3E can configure itself from an Atmel DataFlash. I also include a Xilinx Platform Flash which is programmable via JTAG.
Actually the entire system for ethernet audio streaming with microblaze and peripherals builds in a 3E500 and there is still space left, EXCEPT there isn't enough BRAM so it wouldn't work. For this test platform it will be cool.
oettle said:
I know
oettle said:
Yeah, I know about this new breed of chips, they're quite interesting (although you can't do everything with biquads) however I'd like to try other stuff like doing the oversampling in the FPGA etc... I dunno if I will write a FIR core or use the one from Xilinx, either way it shouldn't be too hard.
What's done :
- Clock & reclock module : schematics OK, missing power supplies. Includes an I2C DAC to control a VCXO. Or just don't solder it and use a normal XO.
- Clock -> DAC connector : pinouts done
- DAC -> Analog module (IV or Output) connector : pinouts done
- DAC -> PSU connector : pinouts done
- Ethernet-less simple FPGA module to test my design before committing to BGA and an expensive PCB : schematics done
I had to re-read all DAC datasheets to be sure not to miss anything in the connectors. That was long.
Next step is to finish my N2PK vector network analyzer that has been waiting for too long and test some decoupling schemes and regulators.
I will also need a low noise amplifier to test for regulator noise with my soundcard. Ideas ?
Meanwhile I can also advance on the schematics for a few more modules. First DAC will be the AK4396 since I have one, and it's voltage out so no need for IV.
See ya
peufeu,
Looking at the CS8406 and CS8416 I notice that the I2C Clock and data lines do not show any pullups, atleast not on this schematic. I2C is bi-directional and hence require pullups. Am i right in assuming that the Spartan3E,Microblaze softcore has the I2C core and is your bus master driving those lines? I2C is very finicky with the clock jitter specifications. The good thing is you are going over the HE-10 edge connector so no worries on matching transmissions lines,phew.But be sure to account for cap loading on the I2C_Clock and I2C_Data lines as you dont want to smear those I2C clocks. This would also dictate the timing for your I2C data. My 1C worth.
Looking at the CS8406 and CS8416 I notice that the I2C Clock and data lines do not show any pullups, atleast not on this schematic. I2C is bi-directional and hence require pullups. Am i right in assuming that the Spartan3E,Microblaze softcore has the I2C core and is your bus master driving those lines? I2C is very finicky with the clock jitter specifications. The good thing is you are going over the HE-10 edge connector so no worries on matching transmissions lines,phew.But be sure to account for cap loading on the I2C_Clock and I2C_Data lines as you dont want to smear those I2C clocks. This would also dictate the timing for your I2C data. My 1C worth.
Thanks for the info. I will put the I2C pullups near the I2C master. You have an idea of a good value for those resistors ?
Yes, Xilinx has an I2C core. Or I could use good old bit-banging in the CPU... sources for that must be somewhere on the Net (even in the Linux kernel, lol) as this would probably save a few slices.
I don't care if I2C is slow, it will only be used at boot to initialize the various components, and ask the tiny I2C EEPROM on the DAC module...
Yes, Xilinx has an I2C core. Or I could use good old bit-banging in the CPU... sources for that must be somewhere on the Net (even in the Linux kernel, lol) as this would probably save a few slices.
I don't care if I2C is slow, it will only be used at boot to initialize the various components, and ask the tiny I2C EEPROM on the DAC module...
10 KOhm,0603 1/16 W resistors pulled up to +3.3V and I2C should be a happy camper. The I2C core should not take up too much logic.We managed to stuff it in to a Spartan 2E device the last time and still did not hog up the resources. Bit banging is slow but cheap compared to chunk of change that you have to pay for Xilinx I2C core.Dont know if there is a free core out there.Maybe there is. Also it is a matter of personal preference, what you are more comfortable dealing with.
Also, too have you decided on the drivers for your Xilinx I/O?
Also, too have you decided on the drivers for your Xilinx I/O?
Re: Re: FPGA?
Hello rfbrw-
I am in agreement with you here, after re-reading my original post it could be surmised that I was suggesting to actually TRY developing a FPGA application using C or assembly programming methods. This was not what I intended to communicate though, I was really just saying that even if you could jump right in with a pre-developed programming skills set, the end result more than likely would not turn out like you might think it would!
I came at developing for FPGAs just like a hardware engineer would have, since that is more along the lines of my job experience. I used to develop custom, high-speed process controls for industrial manufacturing equipment, and since that was during the late 80's there were not very many "affordable" alternatives outside of good old 4000 and 7400 CMOS logic IC chips.....
rfbrw said:
Hello rfbrw-
I am in agreement with you here, after re-reading my original post it could be surmised that I was suggesting to actually TRY developing a FPGA application using C or assembly programming methods. This was not what I intended to communicate though, I was really just saying that even if you could jump right in with a pre-developed programming skills set, the end result more than likely would not turn out like you might think it would!
I came at developing for FPGAs just like a hardware engineer would have, since that is more along the lines of my job experience. I used to develop custom, high-speed process controls for industrial manufacturing equipment, and since that was during the late 80's there were not very many "affordable" alternatives outside of good old 4000 and 7400 CMOS logic IC chips.....
There's an I2C controller available from opencores.org:
http://www.opencores.org/projects.cgi/web/i2c/overview
Just hang it off the microcontroller, like how it is in a PIC or AVR. Using Microblaze to bit-bang strikes me as inefficient.
Alternatively, writing your own I2C controller would be a good exercise. It's not that hard, but there are enough issues to make it "interesting".
http://www.opencores.org/projects.cgi/web/i2c/overview
Just hang it off the microcontroller, like how it is in a PIC or AVR. Using Microblaze to bit-bang strikes me as inefficient.
Alternatively, writing your own I2C controller would be a good exercise. It's not that hard, but there are enough issues to make it "interesting".
I was offline(literally) for the last few days and came back to Civilization and WWW just now.
peufeu,
What I actually meant asking you was whether you have decided on which drive strength to use for your I/O drivers. Choosing the "optimum" drive strength for Signal Integrity. The Spartan-3 devices let you choose 7 different drive strengths ranging from 4, 6, 8, 12, 16, and 24 mA, when you decide if it going to be either LVCMOS or LVTTL I/O standard. The optimum being either 8mA or 12mA drive strength.Anything lesser than would be wimpy. The reason why this would be of great interest to you would be to keep EMI low by choosing an optimum drive strength along with slow output slew rates. This is totally independent of the layout and can be done either before or after your board is laid out. All it takes is different FPGA bit streams for you to decide which drive strength suits your needs.
There is actually a free I2C I/P available at Opencores??.That is spiffy.
Happy new year guys.
peufeu,
What I actually meant asking you was whether you have decided on which drive strength to use for your I/O drivers. Choosing the "optimum" drive strength for Signal Integrity. The Spartan-3 devices let you choose 7 different drive strengths ranging from 4, 6, 8, 12, 16, and 24 mA, when you decide if it going to be either LVCMOS or LVTTL I/O standard. The optimum being either 8mA or 12mA drive strength.Anything lesser than would be wimpy. The reason why this would be of great interest to you would be to keep EMI low by choosing an optimum drive strength along with slow output slew rates. This is totally independent of the layout and can be done either before or after your board is laid out. All it takes is different FPGA bit streams for you to decide which drive strength suits your needs.
There is actually a free I2C I/P available at Opencores??.That is spiffy.
Happy new year guys.
Yeah, OpenCores is nice.
So far we have :
- SPDIF IO Board : done, ready for review.
I modified the layout a bit, did some signal integrity simulations, everything should be OK.
- Cheap FPGA module : done, ready for review.
XC3S500E, no Ethernet, 16 bit SDRAM, XCF Platform Flash, Atmel DataFlash, connectors for : Digital IO board on one side, Reclocking/DAC on the other, JTAG, LCD, buttons, etc. Board will be 4 layers with standard tolerances, so not that expensive or risky to make. Signal, Ground, VCC, Signal. Lots of decoupling caps, resistors in the IO lines, etc. See notes on schematics. I will do the harder BGA once this one works, to have Ethernet and more power.
- Clock / Reclocking board
Schematics done.
- DAC board for AK4396 : done, ready for review.
I happen to have one of those, and it's voltage out, so it will be simpler for the first try. And it's supposed to sound good.
- Filter for AK4396 (Bal -> Unbal and Lowpass)
Schematics done. Placing done, with DIP8 opamps (socketed) and multiple footprint caps (ie. those have several holes to fit many styles of caps).
So, before starting to solder stuff, I still need :
- Layout of Clock and Filter boards
- Power Supply
- Regulators
Get all the files here :
http://home.peufeu.com/nik/dac/DacPlatform-2008-01-02.zip
On the Clock, DAC, and Filter boards I will put some regulators. Those are on pin headers. I will use a symmetrical 10-pin header so the regulators can be plugged both ways in. Also 3 pins doesn't secure much anything physically to the board, so the thing may fall off. 10 pin is better
Obviously though, it will be advised not to swap a +15V reg for a +5V reg to avoid smoke !
The power supply will provide +/- 15V via dumb LM317 so regulators can be replaced by a simple bypass. It will also provide the unregulated voltage on the rail caps so the regulators installed by the user can start with more than 15V to get 15V in the end.
Phew !
I'm looking forward to when that thing is going to be finished !
So far we have :
- SPDIF IO Board : done, ready for review.
I modified the layout a bit, did some signal integrity simulations, everything should be OK.
- Cheap FPGA module : done, ready for review.
XC3S500E, no Ethernet, 16 bit SDRAM, XCF Platform Flash, Atmel DataFlash, connectors for : Digital IO board on one side, Reclocking/DAC on the other, JTAG, LCD, buttons, etc. Board will be 4 layers with standard tolerances, so not that expensive or risky to make. Signal, Ground, VCC, Signal. Lots of decoupling caps, resistors in the IO lines, etc. See notes on schematics. I will do the harder BGA once this one works, to have Ethernet and more power.
- Clock / Reclocking board
Schematics done.
- DAC board for AK4396 : done, ready for review.
I happen to have one of those, and it's voltage out, so it will be simpler for the first try. And it's supposed to sound good.
- Filter for AK4396 (Bal -> Unbal and Lowpass)
Schematics done. Placing done, with DIP8 opamps (socketed) and multiple footprint caps (ie. those have several holes to fit many styles of caps).
So, before starting to solder stuff, I still need :
- Layout of Clock and Filter boards
- Power Supply
- Regulators
Get all the files here :
http://home.peufeu.com/nik/dac/DacPlatform-2008-01-02.zip
On the Clock, DAC, and Filter boards I will put some regulators. Those are on pin headers. I will use a symmetrical 10-pin header so the regulators can be plugged both ways in. Also 3 pins doesn't secure much anything physically to the board, so the thing may fall off. 10 pin is better
Obviously though, it will be advised not to swap a +15V reg for a +5V reg to avoid smoke !
The power supply will provide +/- 15V via dumb LM317 so regulators can be replaced by a simple bypass. It will also provide the unregulated voltage on the rail caps so the regulators installed by the user can start with more than 15V to get 15V in the end.
Phew !
I'm looking forward to when that thing is going to be finished !
News :
Everytime I touch this it seems I had forgotten something. The other day I realized I had forgotten to level-translate one of the lines from 3.3 to V. Anyway.
- I added a connector for an ADC. I have an AK5393 sample...
- I touched up the boards with more relaxed design rules (I'm thinking about having the boards made in china or something).
- Place & route for everything that was waiting is done.
I just need to make the power supply.
I'll post the last version of the stuff tomorrow, I think.
Yay !
Everytime I touch this it seems I had forgotten something. The other day I realized I had forgotten to level-translate one of the lines from 3.3 to V. Anyway.
- I added a connector for an ADC. I have an AK5393 sample...
- I touched up the boards with more relaxed design rules (I'm thinking about having the boards made in china or something).
- Place & route for everything that was waiting is done.
I just need to make the power supply.
I'll post the last version of the stuff tomorrow, I think.
Yay !
Yes, thanks !
Update :
OK. Many, many changes since last time. I redid the layout of the FPGA module (looks much better now), added a module (CDP slaver). Look at the notes in the schematics
Here : http://home.peufeu.com/nik/dac/DacPlatform-2008-01-12_rev0.2.zip
I'll be unavailable for a week, then I'll have to do the power supply board, and order parts.
Do you have suggestions for the PSU ?
See ya
Update :
OK. Many, many changes since last time. I redid the layout of the FPGA module (looks much better now), added a module (CDP slaver). Look at the notes in the schematics
Here : http://home.peufeu.com/nik/dac/DacPlatform-2008-01-12_rev0.2.zip
I'll be unavailable for a week, then I'll have to do the power supply board, and order parts.
Do you have suggestions for the PSU ?
See ya
If you think that you might want some insurance by choosing a switcher instead of a linear, then go for it.Switchers are really good for high slew rate loads such as FPGA cores,processor cores because of their excellent transient response. But again, There are a few crummy details to look at. Switchers tend to put out beat frequencies which are at random harmonics of the fundamental switching frequency. These could extend all the way down the audio range unfortunately. This prompted to Synchronize the switcher to some multiple of the system clock, so that the frequency components are within a known spectrum thereby making the output filtering simple. There are plenty of these available from Linear Tech. Some of these are monolithic meaning the Top Fet is integrated and all you need to supply is the inductor, input bulk,bypass and output bulk and ferrite beads for pi filtering. Some of these can provide upto 5Amps peak.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.