06-04-2012 03:06 AM
I would like to ask you if i am on the right way. i need to build a filter that equalize a channel.
Basically i have a signal from 200Mhz to 800Mhz sampled at 2.175Ghz.
i am working on a virtex5 (xc5vsx95t with 640dsp).
every clock cycle( @ 137 MHz = 2.175Ghz/16), 16 samples taken from the ADC are sent to a processing block and then sent to the DAC.
what i am doing now in the processing block is taking the 16 samples and put it on FIFO.
then i write a FIR filter with 63 taps and exploiting the simmetry of the FIR coefficent i need only to make 32 multiplication.
the FIR filter has 63 samples of input and one samples of output, mathematical is doing this
y = sum h(i)*x(i) with i= 0 to 62
i generate 16 of this FIR filter, the first one take from the FIFO the samples between 0 and 62, the second betwen 1 and 63, and so on.
then i collect all the output and send them to the DAC.
so my question are:
Is there another way more efficent?
or how can i improve my system, which means make a fir filter with a greater number of taps.. now i am using 512 DSP (32 * 16), this means that with this architecture i cannot double the lenght of the filter.
I was wondering that maybe i can double the clock frequency to obtain a better filter
06-05-2012 12:44 AM
can you explain the ADC setup a little more?
These 16 samples from the ADC, are they transfered parallel with a rate of 137MHz to the FPGA?
(Even with 8 bits, this would mean 128 pins for the data input alone, is that true?)
Once you got the 16 samples in your FPGA, they can't be processed at the original sample rate of 2.175Ghz.
So, is this system not runing on a continuous input but only on small snapshots of 16 samples, am I right?
If you have a gap between these chunks of data anyway, is there a maximum time for it?
What is the application behind this?
Why are you sampling at 2.175Ghz?
A sampling rate greater than 1.2GSPS would be sufficient for your signal, but yours is almost twice that value.
Is there some reason for this?
Have a nice simulation
06-05-2012 01:53 AM
to keep it simple i will say yes.. i receive 16 samples in parallel every clock cycle from the ADC at the frequency of 137Mhz, (basically the adc clock cycle / 16), 16 * 16bit are 256pins of data.
all the process is done with this clock rate.. at 137Mhz. it doesn't matter how much is the delay between sampling the signal from the adc and playing in the DAC
no..the system runs on continuos input, it reads data from the adc, it put it on a fifo, process it, and play it back, but there is no gap between chuncks of data.
the application is, a signal is recevied, amplified, downconverted and filtered and sent to the adc, the fpga should compensate for the analog component frequency dependency, then sent to the dac, upconverted, amplified and sent to the tx antenna.
the max frequency of the signal is 800Mhz, for nyquit the sampling frequency should be 1.6Ghz, but actually we just took the maximun adc speed.
06-05-2012 07:11 AM
Ok, but the FIR has to run at the original sampling rate in order to process the samples continuously.
If you feed in 16 samples on each 137Mhz Clock cycle but the FIR processes only one sample at a time, what about the other 15 samples?
(You might be able to use a resizing fifo (16 words in, one word out) but this doesn't compensate the fact that yor sampling data comes in 16 times faster than your FIR can process it.
So, how will you solve this?
Actually Niquyst says that Bandwidth has to be smaller than twice the sampling frequency.
And (800-200)MHz * 2 equals 1.2 GHz. Remember, you mentioned a lower limit for the input frequency. ;-)
Have a nice synthesis
06-05-2012 07:43 AM
06-05-2012 11:08 PM
thanks for the explanation now things are getting more clear.
So you have 16 filters working in parallel on a downsampled version of your original signal.
(Downsampled, because every filter just gets one of 16 samples.)
It's like you would feed your filters with samples taken at a rate of 137 MHz, just that the samples for each stage have a slight delay.
An interesting approach.
I'm quite amazed that spliting up the signal and recombining it afterwards after going through the filters gives a correct result. Is there some name for this method? It reminds me a little of CIC (aka Hogenauer) Filters. Or is it just that?
You know that there's a CIC compiler available in sysgen and Coregen?
For the implementation:
Since you need the filters to run at full clock speed (137MHz) you need a full pipelined architecture, resulting in some very large design. Just like you described.
Doubling the clock frequency (if possible) can help you saving some ressources. But this also means that you have to rebuild your filter architecture to make coefficients switchable and store the intermediate fir results. Have you checked wether some IP like FIR-Compiler can help you at optimizing your design?
Have a nice synthesis
06-06-2012 02:27 AM
Hi thank you for your answer, yes..you understand right.
so my problem is that I receive 16 samples each clock cycle and i have to keep everything in parallel if i want to process and playing it out.
i have tried to take a look at sysgen and coregen, but since i am not very skilled, i didn't understand if they can work with with parallel data, so at first for me was easier to came out with this solution.
no, it is not a CIC filter, the goal is to compensate some frequency behavior of the analog part, so i thought that a fir filter could have been the solution. with 60 taps works quite well. but i want to improve it.
the filter i have build is fully pipelined and yes it uses a lot of resources and took 2 hour to compile :) but the bottleneck now are the limited number of dsp, each filter uses 32, multiplied by 16 i reach 512.. i can grow a little more till 80 taps and reach the limiti of 640dsp
i think that doubling the clock it is possibile since the dsp could work till 550Mhz, but before start to try this way i wish to know if there are more smart solution.
thanks for your help
06-06-2012 03:36 AM
doing the FIRs with sysgen shouldn't be a problem, since the dataflow is controlled by you. With HDLs you are doing basically the same in a textual way rather than graphically. Of course, the calculation of the filter coefficients must be done by you, if the FDA-Tool can't be used for this special architecture. (But you have done this already.)
You might already have worked this out, just for completeness:
What kind of filter have you designed?
May some other filter characteristic be benefitial and reduce the required order of the filter?
Have anice synthesis
06-06-2012 05:02 AM
i will try sysgen, btw the project is:
let's H(f) be the transfer function of all the analog part in my system. i have to build a filter G(f) that make G(f)*H(f) = 1
so what i am doing now is estimate H(f), and compute the IFFT(1/H(f)), then use the first 32 values from the origin as coefficent for the fir (exploiting simmetry i came out with 63 filter lenght)
i thought about fir filter because it is simpler to compute the coefficent and it keeps the phase linear
06-07-2012 01:05 AM
isn't that a compensation filter application?
Maybe a look at this paper might be interesting for you.
They are using CIC filters, and one great advantage of these filters is that they don't use multipliers at all.
Have a nice synthesis
06-12-2012 02:56 AM
yes.. it is.. i have take a look at this CIC filter.. they are very intersting but from what i can read i have to think about also how to compensate they behavior, well this can be solved inside the filtering, but anyway they allow to increase or decrese frequency.. but actually my signal bandwith cover almost al the sampling spectrum (from 0.2 to 0.7) but i don´t need to slow down frequency and neither go up.
In these day i have manage to double the filter clock, so i reach now a filter of 128taps of lenght using 528dpsp working at 271Mhz. I am wonder if this could be enough or i should double the clock one more time so I can reach a filter lenght of 256taps. Is there any formula that links the filter lenght with the ability of compensation?
06-12-2012 10:45 PM
the best result will always be acheived with a FIR-filter of infinite lenght.
Only drawback is that at this length you will never see any result at all. ;-)
No matter what filter you will use, it can always only be an approximation to the optimal result.
Not just that the complexity of the inverse transfer funktion of your analog parts might be difficult to create, but it also might change over time, (e.g. due to temperatue humidity or aging). These effects can't be compensated with a simple filter. The keyword to face these problems is "adaptive filtering", but this neither make things simpler, nor guarantees better results in all cases.
You are working with a very high bandwidth. Are the signals equally distributed within this frequency range? Can you divide it into subbands? A smaller subband may have a less complex transfer function and so better results might be achieved with a smaller filter.
You are trying to solve a complex problem with a very straight forward approach. The problem with that is that this way often leads to very ressource hungry solutions. (e.g. I was trying to create some narrow Band pass filter. With FIR it had a ridiculously high order, changing to IIR reduced the order to below 20. The big drawback: There is no IIR Compiler in the Xilinx IP collection, so I had to design/draw/code it all by myself.)
Maybe there are other approaches to your problem that give an acceptable result with less ressource demand.
Have a nice synthesis
06-13-2012 02:19 AM
Hi, thank you very much for your help, you guess the goal of the project.. compensate temperature and aging effect on the analog part.
why do you say that a simple filter cannot compensate for these effect?
I can estimate the all analog part and compute the filter coefficient and then apply it.
(this is done in python :) )
the system doesn´'t have to behave with a perfectly flat frequency response.. some ripples are tollerated, but they have to stay within a certain amount.
the signal cover all the bandwitdth with the same amplitude, from 200Mhz to 800Mhz, it is like a chirp function.
well, the resource are not a problem.. the only thing this fpga has to do is processing this signal.. so i can use almost every single flip flop :)
IIR filter are quite problematic, first because of the non linearity of the phase and then also the computation of the coefficente is more complex.
06-13-2012 04:15 AM
if you want to compensate temperature and aging effects, you need to determine the TF (transfwr function) of the analog part over time, as it changes. Then invert it and calculate the FIR coefficients. Can your system do this automatically? In that case you already have some sort of adaptive filter.
So how do you estimate the temperature changes of your analog part during runtime?
You surely can do min/max calculations and check wether the signal is still within the field of tolerance, but the changes in the signal caused by some effect can not be eliminated this way.
(Or is it just for some short time running lab experiment?)
The example with the IIr was just meant to show how a differnt approachcan change the ammount of hardware needed. Of course nothing comes for free, as you mention the nonlinear phase properties. But for some applications this might not be a problem. And for calculating the coefficients, well thats clicking one button in the Matlab FDA-Tool to switch between FIR and IIR for a standard filter. In your case it might be different.
But this was just intended to be a generic example, not a useful alternative for your problem.
Have a nice synthesis
06-13-2012 05:00 AM
yes yes the system can do this, basically the system goes in a calibration mode and generate a signal that cover all the bandwith, the signal pass thoruhg all the analog component and it is recorded. Now the channel estimation is very rough.. i just took the ratio between the fft of the transmitted signal and the fft of the received signal
then filter coefficent are computed and applyed to the filter, and then the system goes back in runtime mode.
so the filter has to take care of equalizing the analog component and also all the changes due to temperature or aging
06-13-2012 05:51 AM
well, that's great. Maybe you should have mentioned that before.
It's quite hard to be helpful if only a part of the system is explained but influenced or depending on other parts.
Since the estimation is done with a python script, I suspect that there's some heavy CPU involved as well (at least some ARM if not x86/x64) beside the FPGA.
But if you say that the channel estimation is very rough anyway, how can you expect the TF-linearization done with the FIR to be any better than that? Or is your estimation still better than what you could acheive with a 64 or 128 tap FIR?
And if you are doing FFT for the estimation, why aren't you using a similar FFT/IFFT combination for the FPGA too.
In that case you could directly apply the gain coefficients for the different frequency samples, without the need to calculate FIR-Coefficients. But probably the FFT used fo the estimation is too big to fit into an FPGA for a real time application.
Have a nice synthesis
06-13-2012 06:18 AM
hi, yes.. beside the fpga there is a linux server that can be used for doing the needed processing,
but when in runtime mode the system must be real time, so it not possibile to perform the fft on the fpga.
the channel estimation is rough, with this i wanted to mean that there should be other way to estimate the channel in a better way.. but it is still a problem that i have to solve.. but anyway.. for now it is ok, i can compensate for some ripple that are present in the channel..
i have read something about FIR Least squares inverse Filter that seems to fit very well to my problem