fpga4fun.com

Hi everyone,

I want to develop a small FPGA based project in an effort to learn more about FPGA's and to get some extra experience in hardware design and development. I completed a Bachelor of Computer Engineering four years ago and so have some background in digital hardware engineering (though not using FPGA's), however I have been working mostly in desktop software development since university and so want to brush up on my hardware based skills.

The project is something I am going to call an “EDrum Buddy”. I own a set of electric drums and I want to make this device to perform some useful functions to help me out. I decided on this because I think I can start off creating a really simple project and then slowly add more complex components to the design as I go.

The first step for now is simply to create a digital mixer:
4x analogue inputs (2x stereo inputs) with independent volume controls to 2x analogue outputs (1x stereo) with volume control (and supporting a low impedance load such as headphones). This is so I can mix the sound from the electric drum kit and say a MP3 player together and listen to them through head-phones.

Following the first step, I have thoughts on many useful features I can add to this device with differing complexities (obviously adding additional hardware as necessary):
* Metronome
* Audio processing effects (E.g. Reverb)
* Beat monitor (Attempts to guess the BPM you are playing at)
* Built-in guitar tuner
* Internal MP3 player


I would start with a basic platform:
* 4x ADC's, 2x DAC's
* FPGA
* 3x Seven segment LED displays
* 3x Input buttons for select, up, down (Volume, line selection, metronome configuration)
* Other support hardware (Power supply, FPGA configuration, required amplifiers)

Future options I may extend to add the following hardware to help with extra features and to experiment with the hardware design:
* DSP
* Internal speaker and second audio line out
* Internal flash memory (MicroSD or similar)
* USB interface
* LCD
* Expansion bus of some kind. So can add daughter boards for additional functionality


Some questions

* What is the best way to test an FPGA integrated with the rest of its environment without having completed PCB's?

I was planning on purchasing the Xilinx(R) Spartan(R)-3A Evaluation Kit from Avnet and creating a cable to interface the IO pins to a breadboard. Is this a kind of standard method for evaluating integrated designs?

* What is the standard practise to move from a development board to a PCB where the configuration of the FPGA is no longer performed by the development board but by my design on the hardware? Is there anything I need to look out for?

I can imagine this is a fairly typical audio based application. As I understand it, standard audio output for line and headphone out is a +-1V pp signal or there abouts. With headphone output able to drive a low impedance load and the line out generally expecting a high impedance load.

* Should it be suitable to use any ADC capable of sampling +-1.5V pp (or 0 to 3v with me providing a +1.5v offset to the incoming signal) with a sampling rate of over 44k samples per second?

* Does anyone with experience in this know of any pitfalls I may have to contend with developing such an audio to digital system (like do you sometimes find equipment that has a much larger or smaller voltage range, how about DC offsets etc)?

* Additionally, with the ADC's, DAC's, would I be best looking at SPI based interfaces to reduce the number of pins used on the FPGA?

* Should I use some form of opto-isolator on the audio input to avoid ground loop and input voltage protection? If so and if so any suggested specs for such devices?

I have not used analogue opt-isolators before, and wonder if they will have too low an input impedance, or will change the characteristics of the input signal in any noticeable way?

* Should I put a pre-amp before the ADC or will digital amplification in FPGA be “good enough” for this application? If I do, I would like the pre-amp to be digitally controlled, any suggested devices for this (some kind of Automatic Gain Control)?

Finally, does anyone have advice before I start spending money on hardware?

Well I think I can answer the ADC/DAC part of that...

I'd recommend using dedicated Audio ADCs, Audio DACs or a combined chip (called a "CODEC"), rather than general-purpose ADC/DAC. These audio chips are designed to sample at particular rates, close to Nyquist limit, and they have built-in antialiasing filters (which other ADC/DAC don't have). They are also low-noise. Some CODECs have built-in clock generators, volume controls, mixers, pre-amps or headphone amps: basically a sound card on a chip.

Typically they use a serial audio interface called PCM (or I2S, which is similar). You need to provide a master clock, typically 32x or 64x samplerate (often it's the same as the serial bitclock). There may also be a SPI or I2C interface for control: CODECs can be tricky to configure, by the way.
[More exotic interfaces are AC'97 or HDA. These combine audio and control data, on a few wires.]

So, I'd suggest get a FPGA dev board with onboard Audio CODEC, preferably with good documentation and example code. If you need more than one CODEC... either choose a dev kit with expandable modules (I think Avnet have these?); or try to get hold of some CODEC evaluation boards, and connect them to the FPGA board with patch wires (this may be cheaper, and makes it easier to migrate to custom PCB).

If your equipment is isolated from the mains (floating ground), you can connect all your audio grounds together; you shouldn't need opto-isolation. Avoid ground loops.

Good luck!

Nick

Thanks for the information. This is a late reply, but I have used that info from your post to help me decide what I want to do.

I now have an Avnet spartan 3A eval board, and have built up a breadboard using a Wolfson WM8731 Audio CODEC chip:

http://www.wolfsonmicro.com/products/WM8731/

I am about to hook it up to the eval board and start trying some open-cores modules like the I2S and SPI modules to interface with the codec chip.

Before I start, there is one thing I wanted to clarify about the CODEC chip. The chip has a number of voltage input rails:

DBVDD : Digital buffers VDD
HPVDD : Headphone VDD
AVDD : Analog VDD
DCVDD : Digital core VDD

I am happy with most of these, but I am not sure about the DCVDD.

It is listed as a voltage from 1.4V to 3.6V (typically 1.5V). The others are 2.7 to 3.6V (typically 3.3V).

Should it be fine for me to just provide 3.3V for this DCVDD along with the others? It is in the allowable voltage range, but for some reason it is "typically" 1.5V. Why would the digital core be typically 1.5V? Is it just to reduce the power consumption?


I was thinking of asking this question of the Wolfson technical support, but to date my experience with asking technical support questions (of other companies as part of this educational project) when I only plan on purchasing a very limited number of parts does not get me further than an annoyed representative. So i thought I would ask here instead.

Thanks,
Brendon.

Well, I hope I gave the right advice -- this kind of chip should give good results in the long run, but can be tricky to get it working without tech support -- there are lots of registers to set up. [I hope you have access to an oscilloscope, or a frequency counter, or can do some kind of logic analysis on the FPGA: you may need it to check that the clocks and I/O signals are doing the right thing...]

I guess you're right about DCVDD: to save power they recommend a lower voltage, but typing them all to 3.3V looks OK(as far as I can see).
BTW the datasheet says that the DCVDD can't be greater than AVDD or DBVDD: something you'd have to bear in mind if you'd been planning to filter or regulate AVDD separately.

One last thought: When you get round to audio effects, try to minimize delay. If a drum sound is more than a couple of milliseconds late, I expect you'll notice. For echo/reverb effects, maybe best to use the analog mixer for the main path, with digital processing just to add in the echo...

Regards,

Nick