Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Digita audio and FPGA

Status
Not open for further replies.

andrea_mori

Member level 2
Joined
Aug 14, 2012
Messages
44
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,727
I'm new to FPGA design, so I need some tips to start a digital audio project.
I'm planning to build a discrete ladder digital to analog converter with the following features:

- I2S input 16/24/32 bit 44.1/88.2/176.4/48/96/192 kHz sample rate (maybe also 352.8/384 KHz)
- 24 bit ladder network (last 8 bit discarded) at the above sample rate
- ladder network: 6 bit thermometer + 18 bit R2R
- sign magnitude notation
- voltage output
- ladder fed by parallel data: 2 x 23 mosfet switches + sign
- latch with several OCTAL D-TYPE FLIP-FLOPS
- mosfet switches and ladder isolated from the logic using digital isolator
- 2 external master clocks at 22.5792/24.576 MHz (or 45/49 or 90/98 MHz, depending on the speed required from the FPGA to do its job)

The FPGA should:
- receive I2S (BCK, WS and DATA)
- detect the sample rate
- detect the bit depth
- store data in a FIFO (SRAM at least 4Mb)
- select the right sample rate family (44.1x or 48x) to choose the right external oscillator
- read data from the FIFO
- add some bits if required (input 16/24 bit)
- convert the notation from 2's complements to sign magnitude
- decode the thermometer MSB, 6 to 64
- provide the sign to the digital isolator
- output parallel data, 81 I/O per channel (162 I/O total)


I have some questions for FPGA experts:
- I assume to use the I2S clock (BCK max: 12.288 MHz for 192kHz/32 bit or 24.576 MHz for 384kHz/32) for FPGA timing to manage I2S receiver and store data in the FIFO. Is that correct?
- Then I assume that the FPGA should run at higher clock to manage the other process. Correct?
- So I have different clock domains inside the FPGA. How can I select the right speed clock to do the other processes?
- The latch clock for the DAC is the most crucial signal to generate. Do you think is it better to generate the latch clock from the FPGA or externally dividing the master clock oscillators (for example using something like a 74AC161 counter)?
- What FPGA do you suggest?
- What mux device to switch between the 2 master clock?

I cannot solder BGA, so to build a prototype I need an FPGA development board. Is there any FPGA dev board with such this I/O (around 200)?


Any tips will be very appreciated.
Thanks
 

I have some questions for FPGA experts:
- I assume to use the I2S clock (BCK max: 12.288 MHz for 192kHz/32 bit or 24.576 MHz for 384kHz/32) for FPGA timing to manage I2S receiver and store data in the FIFO. Is that correct? It'll be a good approach as long as the I2S clock is always running.
- Then I assume that the FPGA should run at higher clock to manage the other process. Correct? Yes.
- So I have different clock domains inside the FPGA. How can I select the right speed clock to do the other processes? You don't really need to select...each domain will be clocked by its own clock and safe clock crossing mechanisms will be applied that data is transferred correctly between domains. That's usually done using FIFOs.
- The latch clock for the DAC is the most crucial signal to generate. Do you think is it better to generate the latch clock from the FPGA or externally dividing the master clock oscillators (for example using something like a 74AC161 counter)? I would generate it internally.
- What FPGA do you suggest? Either of these will do.
https://www.xilinx.com/products/boards-and-kits/arty.html#hardware
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=921


But what you must do first - is get yourself very familiar with the basics of logic design and HDL (either Verilog or VHDL).
Altera (now Intel) has really great training videos on their website.

You're facing a steep learning curve. As long as you keep your questions clear and specific - this forum will be of great help. Good luck.
 

Thanks for the reply.

I'm not very worried about learning Verilog, since I usually develop in C and C#. My biggest difficult is to understand FPGA architecture to make the basic choices.
So, I have some basic and specific questions:
- how can I determine the min clock I need to get the FPGA processing all the steps after FIFO? In the worst case FPGA should read 2 words of 32 bits each, convert data from 2's complements notation to sign magnitude, decode 6 bit to 64 lines, output 81 bit serial data to feed the DAC shift register, all the steps at 192 or 384 kHz (highest sample rate).
- the development board you suggest are both powered at 1V2, while DAC logic operates at 3V3, so I need some level shifter. Would it be better using 3V3 FPGA like the Cyclone I?
- Can I simulate the result before buying the development board?

Thanks
 

I'm not very worried about learning Verilog, since I usually develop in C and C#.

C and C# programmjng isn't going to make you a good Verilog coder. It's more likely going to mske you a bad Verilog coder, as you won't write hardware descriptions that target proper pipelined design.

Since you are coming from a software background you better have a strong understanding of logic design. You also should avoid all use of for loops until you understand the are not the same as your temporal for loops in C and C#. Also learn the difference between blocking and non-blocking assignments, before writing any code. These are the issues that the majority of newbies with a software backgroud suffer from when switching to HDL coding.
 

- how can I determine the min clock I need to get the FPGA processing all the steps after FIFO? In the worst case FPGA should read 2 words of 32 bits each, convert data from 2's complements notation to sign magnitude, decode 6 bit to 64 lines, output 81 bit serial data to feed the DAC shift register, all the steps at 192 or 384 kHz (highest sample rate).

Each "step" will by performed by individual logic blocks in FPGA, that's completely different to sequential processing in a CPU. Clocking isn't respectively very critical for audio processing. A reasonable core clock is in the 40 to 50 MHz range, you can it possibly set to an integer multiply of the audio sample rate and run the whole application in a single clock domain.

- the development board you suggest are both powered at 1V2, while DAC logic operates at 3V3, so I need some level shifter. Would it be better using 3V3 FPGA like the Cyclone I?
Basically a misunderstanding. All recent FPGA have core supply voltages around 1V, but support IO voltages up to 3.3V.

- Can I simulate the result before buying the development board?
Simulating your design is strongly suggested in any case.
 

It doesn't sound like there is any processing other than moving data around. A 4Mbit fifo is fairly large -- 114-128 BRAM on a xilinx device. If this is actually needed, it is likely better to have it external.

It isn't clear why there are two external clocks, nor what you intend to do with them. Keep in mind that the output clock should match the input rate, otherwise you would need to resample.

12MHZ might be fine to use for the entire design, it isn't clear if you are doing anything in the FPGA.

I2S could run from an external clock, but this isn't required.
 

C and C# programmjng isn't going to make you a good Verilog coder. It's more likely going to mske you a bad Verilog coder, as you won't write hardware descriptions that target proper pipelined design.

Since you are coming from a software background you better have a strong understanding of logic design. You also should avoid all use of for loops until you understand the are not the same as your temporal for loops in C and C#. Also learn the difference between blocking and non-blocking assignments, before writing any code. These are the issues that the majority of newbies with a software backgroud suffer from when switching to HDL coding.

You are right, but there is a thing to take in the right consideration: I'm an hobbyist that likes to build audio devices and share them with the audio community. Sometimes I supply bare PCB, usually i loose money.
If this was my job I surely would source the FPGA design from an expert, but since it's an hobby I cannot pay for the job, and I believe I can't find anyone available to design it for free.
This will be my first and last FPGA design, basically I'm interested in analog audio rather than digital. But since DAC design moved to Sigma Delta (the last ladder dac, the PCM1704, is an obsolete part) there is only a way: build my own ladder DAC.

So I would limit my learning curve to the minimum that's necessary for this project. I'm not interested to understand all the FPGA world. Jitter is one of the most problem in digital to analog conversion, and FPGA doesn't help. I wouldn't use any PLL in a dac . But they help to save logic devices and space.
I'm trying to understand with the help of experts what is the best architectural approach to do the job using FPGA: development board (maybe with the final device), clock crossing, how to limit jitter issues, and so on.
This could be the starting point to limit the learning job.

- - - Updated - - -

It doesn't sound like there is any processing other than moving data around. A 4Mbit fifo is fairly large -- 114-128 BRAM on a xilinx device. If this is actually needed, it is likely better to have it external.

It isn't clear why there are two external clocks, nor what you intend to do with them. Keep in mind that the output clock should match the input rate, otherwise you would need to resample.

12MHZ might be fine to use for the entire design, it isn't clear if you are doing anything in the FPGA.

I2S could run from an external clock, but this isn't required.

The FPGA simply should provide serial data to feed the ladder shift register, converting the I2S incoming signals. Adding trailing zeroes if needed (bit depth lower that 32 bit), converting 2's complements notation to sign magnitude notation, decoding first 6 MSB to 64 (ladder is segmented, thermometer for the first 6 MSB, R2R for the remaining 17 bit, plus the sign). Finally, serial data are 81 bits per each channel.
I haven't to resample, the output sample rate will be the same as the input. But I would limit jitter issues, so I wouldn't use the input I2S clock (WS) to latch data into the ladder switches. External clocks should provide the latch clock at 44/88/176/352 kHz or 48/96/192/384 kHz. I have 2 sample rate family (44x and 48x), so I need 2 clock family.
I believe the FIFO should be asynchronous, having crossing clock. I could use I2S bck to store incoming data in the FIFO, then the external clock should latch actual word and ask the FPGA to provide one more word (81 bits per channel).
The FPGA should do its job before the latch clock asks for a new word, within a sample rate period.
 

The issue is that a crystal will have some amount of drift and inaccuracy. This can be reduced to something low with thing like an OCXO, which maintains the crystal at a constant temperature. this means you either have to change the clock rate or you need to change the sample rate. This is either a PLL (or something similar) or a resampler.

Luckily, the design is simple and the clock rate is low, so there are minimal issues with SW-style coding.

The other question here is if you plan to use the FPGA to delay the output signals calibrate the turn-on/turn-off behavior at the ladder.

4Mbit seems like a very large fifo, I'm not sure where you determined the size.
 

Basically a misunderstanding. All recent FPGA have core supply voltages around 1V, but support IO voltages up to 3.3V.

Do you mean that recent FPGA can accept 3V3 input but also can provide 3V3 outpt?
Logic after FPGA need at least 2V5 as High Level Treshold.
 

Do you mean that recent FPGA can accept 3V3 input but also can provide 3V3 outpt?
Logic after FPGA need at least 2V5 as High Level Treshold.

Most of the recent FPGAs have programmable I/O voltages that can be set to 1.5V, 1.8V, 2.5V, and 3.3V. You should take a look at the datasheets of any FPGA (families) you may be interested in to determine what I/O voltages they support.
 

The issue is that a crystal will have some amount of drift and inaccuracy. This can be reduced to something low with thing like an OCXO, which maintains the crystal at a constant temperature. this means you either have to change the clock rate or you need to change the sample rate. This is either a PLL (or something similar) or a resampler.

Luckily, the design is simple and the clock rate is low, so there are minimal issues with SW-style coding.

The other question here is if you plan to use the FPGA to delay the output signals calibrate the turn-on/turn-off behavior at the ladder.

4Mbit seems like a very large fifo, I'm not sure where you determined the size.

Long term stability is not an issue in digital audio, the issue is the short term stability, that's the reason I would use external oscillator with low phase noise close to the carrier.
Indeed I'm planning to use an harmonic oscillator with SC-Cut Crystal and oven.

I need a pair of oscillators because I have 2 sample rate families: 44x and 48x MHz. So I have to generate the right latching clock for each family, dividing down one of the 2 oscillators depending on the sample rate family.
FPGA should detect the sample rate family to drive the MUX that will act the switch between the 2 oscillators.

The FPGA will not affect the the turn-on/turn-off behavior at the ladder, the word clock from the external oscillator (at sample rate frequency) will drive the latch of the LVC595 shift register.

4Mbit are 0.16 sec of music at 384kHz sample rate and 32 bit depth, maybe is too large, I only would avoid to get the FIFO empty.

- - - Updated - - -

Most of the recent FPGAs have programmable I/O voltages that can be set to 1.5V, 1.8V, 2.5V, and 3.3V. You should take a look at the datasheets of any FPGA (families) you may be interested in to determine what I/O voltages they support.

Just checked the Cyclone V, it supports 3.3 V LVTTL/3.3 V LVCMOS, with 3V3 VCCPD.
Thanks
 

4Mbit are 0.16 sec of music at 384kHz sample rate and 32 bit depth, maybe is too large, I only would avoid to get the FIFO empty.

160 ms is an eternity with a 44(48) MHz system clock (i.e. that is 61,440 samples), if your music input has that much jitter then you have a system issue that needs to be addressed first.

Assuming you aren't making a design which uses burst packet transfers, it is far more likely your design requires only 160 us of data buffering to work (i.e. around 64 samples based on your 384KHz sample rate) and that would still be overkill.
 

Long term stability is not an issue in digital audio, the issue is the short term stability, that's the reason I would use external oscillator with low phase noise close to the carrier.

Ok, but what happens when the source provides the extra sample or fails to provide it? do you just drop the sample or repeat the sample as needed?
 

Ok, but what happens when the source provides the extra sample or fails to provide it? do you just drop the sample or repeat the sample as needed?

FPGA should lock the incoming I2S signals, if there is no signal FPGA should stop all the processes and no output data will be supplied to the ladder. When will happen a new lock FPGA should reset and restart the process. Reset should be happens on the rising edge of the latch clock.
If the source fails FIFO will be empty, one more error condition to manage stopping all the process.
Typically there is no reason to get the source providing extra samples or failing to provide them, also without music the source provides correct samples (all zeroes). I think the only error condition is when the source is disconnected or off.
 

Ok, this isn't true but might be close enough.

If the source and output clocks are both OCXO's, the long term stability will also be very good. The fifo could several days of use before dropping/duplicating samples.

However, if the source isn't derived from a clock with high long term stability, you could have issues with dropped/duplicated samples. I don't know if they will be audible.
 

160 ms is an eternity with a 44(48) MHz system clock (i.e. that is 61,440 samples), if your music input has that much jitter then you have a system issue that needs to be addressed first.

Assuming you aren't making a design which uses burst packet transfers, it is far more likely your design requires only 160 us of data buffering to work (i.e. around 64 samples based on your 384KHz sample rate) and that would still be overkill.

So do you suggest to use the internal RAM of the FPGA?
 

So do you suggest to use the internal RAM of the FPGA?

This is a design decision. A fifo allows a temporary rate mismatch to be absorbed as well as a clock phase difference to be corrected.

In your application you have a few issues. Clearly you have a phase mismatch possibility of the i2s clock. The external ocxo and fpgas have convenient fifos already built in. The size of a fifo you want, 4 Mbit is somewhat large. If you can afford an FPGA with 4Mb internal storage there would be no reason not to use it. But not all FPGA's have 4 Mbit storage.

In terms of rate switching, realistically you can mute for 1/60th second while determining settings. You'll never be appreciating music while swapping sampling rates several times per second.

As I mentioned, the valid reason for a large fifo would be to support an intentional, small rate mismatch for an acceptable period of time. Two ocxo (or better for long-term stability) clocks will have very little difference. This means a half-filled 10ms buffer would take an acceptable time before normal over/underflow with a 5ms delay which is fine for audio-video matching.

I suggest regenerating the clock from the i2s clock for commercial source applications -- where the source might not have an ocxo or better (in terms of long term stability) clock.



I'm not fully clear on your design requirements. An external board with an io-expander, for example, would make FPGA requirements lower.
 

This is a design decision. A fifo allows a temporary rate mismatch to be absorbed as well as a clock phase difference to be corrected.

In your application you have a few issues. Clearly you have a phase mismatch possibility of the i2s clock. The external ocxo and fpgas have convenient fifos already built in. The size of a fifo you want, 4 Mbit is somewhat large. If you can afford an FPGA with 4Mb internal storage there would be no reason not to use it. But not all FPGA's have 4 Mbit storage.

In terms of rate switching, realistically you can mute for 1/60th second while determining settings. You'll never be appreciating music while swapping sampling rates several times per second.

As I mentioned, the valid reason for a large fifo would be to support an intentional, small rate mismatch for an acceptable period of time. Two ocxo (or better for long-term stability) clocks will have very little difference. This means a half-filled 10ms buffer would take an acceptable time before normal over/underflow with a 5ms delay which is fine for audio-video matching.

I suggest regenerating the clock from the i2s clock for commercial source applications -- where the source might not have an ocxo or better (in terms of long term stability) clock.



I'm not fully clear on your design requirements. An external board with an io-expander, for example, would make FPGA requirements lower.

I have the OCXO in the DAC but not in the source, so I could get rate mismatch in the long period. I should implement some kind of dynamic correction to avoid full or empty FIFO.
One way could be to realign the clock domains during the pause between the songs increasing or reducing the pause. In worst case (symphonic or live music) there is no pause along 40-50 minutes, so I should define the needed RAM for such that condition.

About I/O, finally I decided to feed several shift registers with serial data, so I don't need many outputs, reducing the FPGA requirement.
FPGA will process I2S and provides clock and data to store them in the storage register (LVC595), while the external oscillators provide the word clock to get data to appear at the output of the 595.
FPGA should be fast enough to transfer serial data in the storage registers within the sample rate period, or better before the end of the period, stopping the shift clock before the external oscillators provide the WCLK, avoiding any interference between the clocks.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top