Sampling using the VIC

--- Quote Start ---

I want sample the output of an ADC and store it in registers where it can be processed while another sample is taken. After reading through some Nios literature, it seems like the best way to do this is to use the Vectored Interrupt Controller and the Shadow register sets. Does anyone have an opinion about this? I'd like to write the values sampled from the ADC to the shadow registers. Thanks in advance

--- Quote End ---

It really depends on your ADC sampling rate, and what you want to do with the data.

If your ADC operates under software control, eg., you enable it for a conversion and then get an interrupt when it is done, then a software solution would work fine.

If however your ADC operates continuously at frequencies of ~MHz, then you will have to come up with a different scheme, eg., sampled data would be streamed to a data processing block, where some parameter was estimated by FPGA logic, eg., a power estimate. The NIOS processor would then access the results of the DSP processing at a much slower rate than the ADC clock rate.

So what is your situation?

Cheers,

Dave

--- Quote Start ---

The ADC is for an audio application so the output rate will be quite high. What I need to do first for my project is perform an offset correction and determine the frequency at the input(fast).

--- Quote End ---

In that case, you need to consider the signal processing separate from the NIOS processor. The processor can be used to configure the signal processing path, and to read results, but it would not be involved in processing of individual samples.

What does 'offset correction' entail? Measuring the DC value of the signal, and then adjusting it until it is zero, or simply removing the DC component?

Start by getting a simple example working first, eg., the DC offset, or perhaps the input power, and then work on the frequency estimation.

You should also try and implement the software equivalent of the processing of the samples in a signal processing package like MATLAB. Its much simpler to develop algorithms and look at spectra in MATLAB, and then decide what needs to be implemented in hardware.

Cheers,

Dave

Yes, I am using MatLab to develop the algorithms, I've also been looking at the DSP builder link between MatLab and Quartus but not sure about that yet.

The offset correction removes the DC offset, which I believe will make the data easier for the frequency estimation processing. Do I need to determine the input power for the processor? For the DSP block your referring to the Quartus megacores right?

--- Quote Start ---

I am using MatLab to develop the algorithms

--- Quote End ---

Ok.

--- Quote Start ---

I've also been looking at the DSP builder link between MatLab and Quartus but not sure about that yet.

--- Quote End ---

I haven't used DSP builder. I prefer to code the VHDL directly.

--- Quote Start ---

The offset correction removes the DC offset, which I believe will make the data easier for the frequency estimation processing.

--- Quote End ---

That is probably correct; though it would depend on the algorithm you select. If you were to use an FFT, the DC component results in ringing across the frequency response. Its a good idea to remove it. The book "Understanding Digital Signal Processing", by Rick Lyons has example DC removal circuits.

However, if your audio signal is AC coupled to your ADC, there should not be much of a DC offset. You should capture some data and investigate.

--- Quote Start ---

Do I need to determine the input power for the processor?

--- Quote End ---

No, but you will want to know if your signal is 'loud' enough, otherwise your ADC quantization noise will dominate. I was simply suggesting that you start by figuring out how to design a power measurement circuit, since it is very simple; hint its related to the average of a block of samples squared (simple to implement in hardware).

--- Quote Start ---

For the DSP block your referring to the Quartus megacores right?

--- Quote End ---

No, I just meant signal processing in general. You might want to use DSP blocks (the FPGA resource), but you can infer those by writing code like a*b, where a and b are appropriate sized std_logic_vectors; the Quartus handbook has coding style recommendations.

Cheers,

Dave

Hi Dave,

I myself was a fan of coding by inference since it is compact and readable. This is certainly true for registers and most additions, shifts ...etc. but with multipliers I encountered some issues:

1) compilers tend to infer a mult per occurence in a construct and it does not realise when one mult can do the job. This can be easily avoided by coding style.

2) I can't decide pipeline inside inferred mults.

3) in stratix III/IV there is what is termed dsp element which is made up of 4 mults plus adders in a single block. This block has enough input ports for 4 mults but only 72 outputs meaning that you can only use 2 mults on their own(wasting two) or all 4 mults if you use adders inside. The compiler does not infer these blocks from code (unless there is special way). HDL inference coding needs to catch up for these mini-asic blocks inside fpgas.

With regard to DSPbuilder, I have started using it reluctantly. It offers wonderful development and iteration speed when it works but a painful dilemma if it does not, no one can repair the generated code. Interestingly, while it can be used by beginners , it can be used far more powerfully if designer has prior dsp knowledge. The resource usage and speed are impressive. But... its main drawback as any tool is on the skills of the workforce...

Hi Kaz,

--- Quote Start ---

I myself was a fan of coding by inference since it is compact and readable. This is certainly true for registers and most additions, shifts ...etc. but with multipliers I encountered some issues:

1) compilers tend to infer a mult per occurence in a construct and it does not realise when one mult can do the job. This can be easily avoided by coding style.

2) I can't decide pipeline inside inferred mults.

3) in stratix III/IV there is what is termed dsp element which is made up of 4 mults plus adders in a single block. This block has enough input ports for 4 mults but only 72 outputs meaning that you can only use 2 mults on their own wasting two or all 4 mults if you use adders inside. The compiler does not infer these blocks from code (unless there is special way). Thus HDL coding needs to account for these mini-asic blocks inside fpgas.

With regard to DSPbuilder, I have started using it reluctantly. It offers wonderful development and iteration speed when it works but a painful dilemma if it does not, no one can repair the generated code. Interestingly, while it can be used by beginners , it can be used far more powerfully if designer has prior dsp knowledge. The resource usage and speed are impressive. But... its main drawback as any tool is on the skills of the workforce...

--- Quote End ---

Interesting, thanks for the valuable insight.

What I have been doing with code that needs to use DSP blocks is to write both Altera-IP provided component code, and what I hope to be equivalent generic inferable (sp?) VHDL. I then use a generic and a generate block to select between them. I then look at the RTL viewer to see if I ended up with the same logic. If I want to target this same DSP logic to Xilinx or Lattice devices, I'll add new generic values, and new generate blocks, and use their components and inferable VHDL.

Regarding inferred logic vs generic VHDL, out of habit I use lpm_counter's directly, so I can access their carry-out signals as the 'done' indicator to FSMs. I always found that a generic VHDL counter and zero-detection logic would also use more logic cells. I think when I tried this recently, I got about the same number of logic cells, so the synthesis tool has got better. One could also argue that with today's 1M logic cell devices, that those sorts of inefficiencies could be tolerated ... but I still find it annoying :)

Cheers,

Dave

Thanks For your advice Dave. Can you tell me what relevant limitations the Nios processor has vs. the fpga, will it not process at the same speed the fpga does?

-Sam

Hi Sam,

--- Quote Start ---

Can you tell me what relevant limitations the Nios processor has vs. the fpga, will it not process at the same speed the fpga does?

--- Quote End ---

A processor has to fetch instructions, fetch data, perform an operation, and then write the result somewhere. The FPGA fabric can process data in a 'streaming' fashion, where data comes in one set of ports, gets processed, and leaves by another set of ports. The only limit to the operating speed of that logic is the clock rate of the FPGA. If your ADC sampling rate exceeds the FPGA maximum clock rate, then you can still process the data, but you have to do it in parallel.

In many signal processing systems, processing is performed by the FPGA fabric, while a processor is used for control; enabling blocks, selecting processing blocks (multiplexer control), and monitoring what is going on. This is why the Avalon bus used by Altera has two implementations; the memory mapped Avalon-MM read/write interface for processor buses, and the streaming Avalon-ST unidirectional interface for connecting DSP blocks (or DMA, or whatever has a streaming nature).

Cheers,

Dave

@vogels

dc filter is a special case of high pass filter.

for dc removal I can think of one well known 1st order IIR filter:

Hz = (1- z-1)/(1-az-1)

in matlab:

num =[1 -1];

den =[1 -a]; where a = fraction e.g. 0.95

This is in effect running average subtractor.

example: your input is 8 bits. you accumulate say 1024 samples in a large enough adder(18 bits) then take 8 MSBs of adder result to subtract it from input in a feedback loop.