Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Jul 3, 11:52=A0am, chewie <timinganaly...@gmail.com> wrote: > Thanks James. =A0I did post a similar message on comp.lang.python. > If there are some speed bottlenecks in Python, =A0there is always the > option > of writing only those parts in a C extension.- Hide quoted text - > > - Show quoted text - Personally... I wouldn't bother optimizing it with a C extension. Programmer time is more expensive than computing time. Computers are getting faster every year. Soon, the slow parts might not even be noticeable. PeteArticle: 141751
vizziee wrote: > Hello everyone, > > I am trying to design a low pass decimator filter in MATLAB. "MATLAB does all thinking for us" (TM) > I am > supposed to decimate a signal sampled at 200MHz down to 10MHz. The > signal bandwidth is 8 MHz and the signal spectra is centred at the > sampling frequency. How do you manage 8 MHz of bandwidth at 10 MHz sampling rate? VLVArticle: 141752
> be ceil(1005/M1) = 50 and so I would have M1=20 such filters. Would A correction here: ceil(1005/M1) = 51. Regards, vizziee.Article: 141753
On Jul 6, 11:50=A0am, Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote: > > I am > > supposed to decimate a signal sampled at 200MHz down to 10MHz. The > > signal bandwidth is 8 MHz and the signal spectra is centred at the > > sampling frequency. > > How do you manage 8 MHz of bandwidth at 10 MHz sampling rate? > > VLV Thanks VLV for your reply. The sampling rate is 200MHz. So an 8MHz BW signal occupies -pi/25 to pi/25 frequency range. When I downsample this signal by 20, the signal occupies -4pi/5 to 4pi/5 frequency range at 10MHz. Is there something that I am missing here? vizzieeArticle: 141754
rickman <gnuarm@gmail.com> wrote: (snip, I wrote) <> This is confusing. The points have zero width and integrate <> to zero. Left out is the actual limit for the integral. If it <> includes one half a sample period before the first point, and <> one half after the last point, then just add. If it doesn't, <> then you need to divide the first and last point by two. (after you wrote) <> < The mistake that is often made when dealing with discrete time samples <> < is thinking that they are the same as the instantaneous values of a <> < continuous function. In reality they are already integrals of the <> < amplitude and the sample period (1/f). That is why you only need to <> < sum them to obtain the integral over a series. <> For the sampling theorem to work they must be samples of the <> instantaneous value. Otherwise the result is filtered and <> the results will be wrong when used as filter input (or almost <> any other use.) (snip) < What you have said is a self-contradiction. If there is no averaging < at all (an impossibility - all measurements are made within a finite < time window) and the point measures a value at an exact point it time, < then there is no bin to be in the center of or at the edge of. They < are just measurements of a point in time. What would define the bin? < In fact, what *IS* a bin in this context? I read both comp.dsp and comp.arch.fpga, and sometimes there is overlap between them. An important part of digital signal processing is the sampling theorem which, briefly, (and ignoring non-baseband signals) states that a signal sampled at more than twice its highest frequency component can be reconstructed from those samples. For any problem involving sampled signals, the assumption, then, is that it was properly filtered before sampling. As integration is a averaging, or low pass filtering, process it tends to reduce any error in the input data, including sampling error. at twice its < It is a matter of perspective which I believe is shown clearly in the < calculations. As I showed above (or I tried to show) the two < calculations performed on an infinite time series are exactly < equivalent and when performed on a finite time series the only < difference is that one method includes all the samples with a < multiplier of 1 and the other uses a multiplier of 0.5 only on the end < points. Yes. If you add up (n+1) points and want the average value you should divide by (n+1) not n. Consider the case where all sample points have the same value. If the length of the continuous integral is n, adding up (n+1) points will give a result (n+1)/n too large. On the other hand, the (n+1) points could be over an interval of length (n+2). If the length is n the sum of the weights of the points should be n. (That is, for at least a 0th order approximation.) If the length is n, one solution is to multiply the first and last points by 0.5, another is to multiply all points by n/(n+1). < The distinction of looking at the "bins" as being around the sample or < between the samples is a red-herring and have no relation to the real < math of integrating a time sampled signal. < | | | |--+--| < | | |--+--| * | < | |--+--| * | * | < |--+--| * | * | * | < | * | * | * | * | < | * | * | * | * | < t0 t1 t2 t3 < 3 4 5 6 < In this example, the + indicate the value of the signal f(t) at that < point in time. The integral calculation assumes that the value of f < (t) between the time samples is a straight line. By treating the < period as "1" and summing the values, you are in effect calculating < the areas shown above with the point centered in the rectangles. The < area on the left and right of the point between the top of the < rectangle and the straight line approximation have opposite signs < since one is making the area larger than it should be and other is < making is smaller. But they are equal in value and cancel. I agree. What is important is the total length of the region being integrated. That could be n, n+1, n+2, or almost anything else. (For uniform sampling, hopefully not too far from one of those.) < The other method draws rectangles between the points with a height < equal to the average of each two points. This is a much more complex < calculation and gives the same result. There is no reason to < complicate the calculations using this calculation. Neither < calculation has a basis in the physics of the problem. They are just < equivalent numerical approximations. If the actual length of the integral isn't too important, I 100% agree. If it is somewhat important, as it often is for not so large n, then I don't agree. Numerical integration routines are often ranked on the highest order polynomial they give an exact result for. (Even though it is rare to actually numerically integrate polynomials.) If you don't even get zero order, that isn't good. Still, in the large n limit it isn't far off. -- glenArticle: 141755
rickman <gnuarm@gmail.com> wrote: (snip, someone wrote) <> < int(n) = int(n-1) + 0.5 * (f(n) - f(n-1)) (snip) < Actually, the difference is that for a finite series, one approximates < the integral of the curve at N points and the other approximates the < integral of N-1 points. I would call it an integral of length N or N-1, but yes. < This is easy to see if you consider the width < of the area being approximated. For a constant value using two < points, the simple sum is twice the value of a single point and three < points gives a value half again as large as two points. Using the < average method you can't calculate a value for one point and the value < for three points is *twice* the value for two points. That's because < the area being approximated using three points is only two periods < wide, not three. < Time sampled series are not continuous functions and can not be < analyzed the same way. Sampled series are often approximations of continuous functions. For band limited continuous functions the sampled series can exactly represent the continuous function. (That is, sampled by not quantized.) As I said previously (before reading your post), it is usual to indicate the highest order polynomial that a numerical integration routine gives an exact answer for. (Ignoring any rounding or quantization errors.) Within certain constraints, time sampled series can be analyzed in a way comparable to coninuous functions. -- glenArticle: 141756
vizziee wrote: > On Jul 6, 11:50 am, Vladimir Vassilevsky <antispam_bo...@hotmail.com> > wrote: >>> I am >>> supposed to decimate a signal sampled at 200MHz down to 10MHz. The >>> signal bandwidth is 8 MHz and the signal spectra is centred at the >>> sampling frequency. >> How do you manage 8 MHz of bandwidth at 10 MHz sampling rate? >> >> VLV > > Thanks VLV for your reply. > > The sampling rate is 200MHz. So an 8MHz BW signal occupies -pi/25 to > pi/25 frequency range. When I downsample this signal by 20, the signal > occupies -4pi/5 to 4pi/5 frequency range at 10MHz. Is there something > that I am missing here? Yes. The bandwidth is not changed by downsampling. The 8 MHz signal lies between 196 and 204 MHz when sampled and between 6 and 14 MHz after downsampling. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 141757
> Yes. The bandwidth is not changed by downsampling. The 8 MHz signal lies > between 196 and 204 MHz when sampled and between 6 and 14 MHz after > downsampling. > > Jerry Thanks Jerry. I think I did a mistake in my description. The signal bandwidth is 8 MHz and the signal spectrum is centred at zero rather than the sampling frequency. So, initially the signal lies between -4MHz and 4MHz in the -100MHz to 100MHz range of sampled signal spectrum. So, after downsampling by 20, the spectrum should lie between -4MHz and 4MHz in the -5MHz to 5MHz range of downsampled signal spectrum. Does this make sense now? Regards, vizziee.Article: 141758
vizziee wrote: >> Yes. The bandwidth is not changed by downsampling. The 8 MHz signal lies >> between 196 and 204 MHz when sampled and between 6 and 14 MHz after >> downsampling. >> >> Jerry > > Thanks Jerry. I think I did a mistake in my description. The signal > bandwidth is 8 MHz and the signal spectrum is centred at zero rather > than the sampling frequency. > So, initially the signal lies between -4MHz and 4MHz in the -100MHz to > 100MHz range of sampled signal spectrum. So, after downsampling by 20, > the spectrum should lie between -4MHz and 4MHz in the -5MHz to 5MHz > range of downsampled signal spectrum. Does this make sense now? That part does. Are you complex shifting? If not, how do you separate positive from negative frequencies? The usual way, a sample raye exceeding twice the bandwidth, evidently doesn't apply. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 141759
> That part does. Are you complex shifting? If not, how do you separate > positive from negative frequencies? The usual way, a sample raye > exceeding twice the bandwidth, evidently doesn't apply. The signal is symmetric in spectrum. So the entire information is available in one half of the spectrum. So coming to my original question, how should I interpret the polyphase coefficients. Regards, vizziee.Article: 141760
On Jul 6, 3:49 pm, vizziee <vizz...@gmail.com> wrote: > > That part does. Are you complex shifting? If not, how do you separate > > positive from negative frequencies? The usual way, a sample raye > > exceeding twice the bandwidth, evidently doesn't apply. > > The signal is symmetric in spectrum. So the entire information is > available in one half of the spectrum. > > So coming to my original question, how should I interpret the > polyphase coefficients. > > Regards, > vizziee. It has been quite a while since I have designed a poly phase fir filter, but if you are going to decimate by 20, don't you need a multiple of 20 coefficients? Otherwise you can't distribute the taps between the phases. A poly phase filter does not reduce the number of taps. It simply takes advantage of the fact that when you decimate the output of the FIR filter, you only need to calculate the outputs that you will be retaining. This reduces the number of calculations performed. If you had 100 taps and the filter produced an output for every input, you would perform 100 multiplies and 99 adds for each output point. The poly phase filter calculates the filter output in pieces so that for a 20x decimation the filter only does 5 multiplies and 4 adds for each input value, but still does 100 multiplies and 99 adds (counting the combining of the phases) for each output. So I don't see how you can use 1005 coefficients in a 20x polyphase filter. I may be missing something, but I don't think so. Also note that for most FIR filters you don't need to store the full number of coefficients. I don't recall the requirement to make this true, but often the coefficients are symmetrical so that coef(0) = coef (n-1). This can be true even if you have an odd number of taps, the middle coefficient is not used twice. To picture what is happening in a poly phase filter, try drawing a diagram of some sort showing which inputs are multiplied by which coefficients and how the phases are added to produce an output. When I did my first poly phase filter I didn't have this fully in hand and I mixed up the phases. The result was not pretty and hard to debug. RickArticle: 141761
rickman wrote: [...] "Let the dumb lead the blind" VLVArticle: 141762
Thanks Rick for your response. > filter, but if you are going to decimate by 20, don't you need a > multiple of 20 coefficients? =A0Otherwise you can't distribute the taps > between the phases. I am zero-padding the filter in practice. > The poly phase filter calculates the filter output in pieces so that > for a 20x decimation the filter only does 5 multiplies and 4 adds for > each input value, but still does 100 multiplies and 99 adds (counting > the combining of the phases) for each output. A polyphase decimator filter would perform fewer computations for each output *per cycle*. > number of coefficients. =A0I don't recall the requirement to make this > true, but often the coefficients are symmetrical so that coef(0) =3D coef > (n-1). =A0This can be true even if you have an odd number of taps, the > middle coefficient is not used twice. Symmetry of coefficients is related with Linear Phase FIR filters. Symmetry is taken care within the usual Xilinx FIR Compiler. So I don't see an issue with this. Regards, vizziee.Article: 141763
On Jul 6, 3:05=A0pm, Vladimir Vassilevsky <antispam_bo...@hotmail.com> wrote: > rickman wrote: > > [...] > > "Let the dumb lead the blind" > > VLV "And let the deaf watch" vizziee.Article: 141764
vizziee <vizziee@gmail.com> writes: > [...] > The signal bandwidth is 8 MHz > [...] > the signal lies between -4MHz and 4MHz These two statements cannot both be true. If you're talking about a real signal, then "bandwidth" is defined as the non-zero portion of the positive frequency spectrum (not positive and negative). Thus the signal as you've defined it in the latter statement would have a 4 MHz bandwidth, not an 8 MHz bandwidth. -- Randy Yates % "Maybe one day I'll feel her cold embrace, Digital Signal Labs % and kiss her interface, mailto://yates@ieee.org % til then, I'll leave her alone." http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELOArticle: 141765
On Jul 6, 1:51=A0pm, vizziee <vizz...@gmail.com> wrote: > > be ceil(1005/M1) =3D 50 and so I would have M1=3D20 such filters. Would > > A correction here: =A0ceil(1005/M1) =3D 51. > > Regards, > vizziee. Vizzie, You should check out using multistage decimation if you want to decimate by 20. A halfband decimating filter, another halfband decimating filter, then a decimate by 5 filter. In the first two stages, in order to cut down the number of taps, don't preserve (alias free) any bandwidth you don't need. Design the final filter as a cleanup to remove aliasing from the 1st 2 filters and do bandlimiting for the final decimation. This is standard practice. This is also NOT a detailed description of how to design these filters. Dirk BellArticle: 141766
On Jul 6, 8:26=A0pm, Dirk Bell <bellda2...@cox.net> wrote: > On Jul 6, 1:51=A0pm, vizziee <vizz...@gmail.com> wrote: > > > > be ceil(1005/M1) =3D 50 and so I would have M1=3D20 such filters. Wou= ld > > > A correction here: =A0ceil(1005/M1) =3D 51. > > > Regards, > > vizziee. > You could use a graychip directly instead of reimplementing that functionality in a FPGA. The graychip functionality provides a CIC filter followed by 2 stages of decimation. The CIC provides a simple but effective decimation mechanism - the next filter also performs decimation but it is also meant to compensate for the droop of the passband in the CIC filter. To understand how to design the multistage decimation filters I would recommend reading Crochiere and Rabiner's (Multirate Signal Processing) - I'm not sure if I've got that reference exactly right. Cheers, David > Vizzie, > > You should check out using multistage decimation if you want to > decimate by 20. =A0A halfband decimating filter, another halfband > decimating filter, then a decimate by 5 filter. =A0In the first two > stages, in order to cut down the number of taps, don't preserve (alias > free) any bandwidth you don't need. =A0Design the final filter as a > cleanup to remove aliasing from the 1st 2 filters and do bandlimiting > for the final decimation. =A0This is standard practice. > > This is also NOT a detailed description of how to design these > filters. > > Dirk BellArticle: 141767
Hello, This might not be the best place to ask but i'd thought to give it a shot. I am running a webserver on a spartan 3an FPGA. My webserver uses yahoo scripts to listen to a submit button with the YAHOO.util.Event.addListener command. Then it gets some data in the FPGA and displays it on a page. My question is how do I get it to automatically submit the request without having to press the submit button everytime? Thanks for any sugestions HVArticle: 141768
> You should check out using multistage decimation if you want to > decimate by 20. =A0A halfband decimating filter, another halfband > decimating filter, then a decimate by 5 filter. =A0In the first two > stages, in order to cut down the number of taps, don't preserve (alias > free) any bandwidth you don't need. =A0Design the final filter as a > cleanup to remove aliasing from the 1st 2 filters and do bandlimiting > for the final decimation. =A0This is standard practice. > > Dirk Bell Thanks Dirk. I tried this design and the number of taps vis-a-vis number of polyphase filters got reduced by 4 (discounting the number of taps in Half-band filters). This is a great savings as. earlier. for the same roll-off I had 200taps for some 20 filters in the polyphase structure. However, my calculations for the processing delay don't match up with my results in the MATLAB: No of taps in the first (Direct Form Polyphase) Half-band filter =3D N1 =3D 22 Processing delay at the output of first Half-band filter =3D D1 =3D ceil (((N1/2) - 1)/2) =3D 5 No of taps in the first (Direct Form Polyphase) Half-band filter =3D N2 =3D 22 Processing delay at the output of first Half-band filter =3D D2 =3Dceil ( ((N2/2) - 1)/2) =3D 5 No of taps in the first (Direct Form Polyphase) Decimate-by-5 filter =3D N3 =3D 1010 Processing delay in Polyphase (decimate by 5) filter =3D D3 =3D ceil (((N3/5) - 1)/2) =3D 101 Total delay =3D sum(D1, D2, D3) =3D 5+5+101 =3D 111 samples However my output only shows a delay of 102 samples after the last filter stage. Regards, vizziee.Article: 141769
> functionality in a FPGA. The graychip functionality provides a CIC > filter =A0followed by 2 stages of decimation. The CIC provides a simple > but effective decimation mechanism =A0- the next filter also performs > decimation but it is also meant to compensate for the droop of the > passband in the CIC filter. To understand how to design the multistage > decimation filters I would recommend reading Crochiere and Rabiner's > (Multirate Signal Processing) - I'm not sure if I've got that > reference exactly right. Thanks David. But as I wrote before, I am not satisfied with the response of CIC-Compensator-HalfBand filter. One of the primary reasons for this is I have three frequency channels to filter and the response of CIC-et.al. filter allows some leakage of the adjacent channels to the output. This is not a problem with the polyphase LPF implementation. Regards, vizziee.Article: 141770
On Jul 7, 2:49=A0pm, vizziee <vizz...@gmail.com> wrote:
> > You should check out using multistage decimation if you want to
> > decimate by 20. =A0A halfband decimating filter, another halfband
> > decimating filter, then a decimate by 5 filter. =A0In the first two
> > stages, in order to cut down the number of taps, don't preserve (alias
> > free) any bandwidth you don't need. =A0Design the final filter as a
> > cleanup to remove aliasing from the 1st 2 filters and do bandlimiting
> > for the final decimation. =A0This is standard practice.
>
> > Dirk Bell
>
> Thanks Dirk. I tried this design and the number of taps vis-a-vis
> number of polyphase filters got reduced by 4 (discounting the number
> of taps in Half-band filters). This is a great savings as. earlier.
> for the same roll-off I had 200taps for some 20 filters in the
> polyphase structure.
>
> However, my calculations for the processing delay don't match up with
> my results in the MATLAB:
> No of taps in the first (Direct Form Polyphase) Half-band filter =3D N1
> =3D 22
> Processing delay at the output of first Half-band filter =3D D1 =3D ceil
> (((N1/2) - 1)/2) =3D 5
> No of taps in the first (Direct Form Polyphase) Half-band filter =3D N2
> =3D 22
> Processing delay at the output of first Half-band filter =3D D2 =3Dceil
> ( ((N2/2) - 1)/2) =3D 5
> No of taps in the first (Direct Form Polyphase) Decimate-by-5 filter =3D
> N3 =3D 1010
> Processing delay in Polyphase (decimate by 5) filter =3D D3 =3D ceil
> (((N3/5) - 1)/2) =3D 101
>
> Total delay =3D sum(D1, D2, D3) =3D 5+5+101 =3D 111 samples
>
> However my output only shows a delay of 102 samples after the last
> filter stage.
>
> Regards,
>
> vizziee.
Vizzee,
Check your equations. I get
( ( (22-1)/2 )/20 + ( (22-1)/2 )/10 + ( (1010-1)/2 )/5 ) =3D 102.4750
which is consistant with what you are actually getting, not what you
are calculating.
Also note that the filters you are identifying as half-band filters
are not actually half-band filters. Half-band filters have the
property that almost half of the coefficients are zero, saving
calculations, which may be useful to you. But, among other properties,
the lengths of halfband filters are constrained to {3, 7, 11, 15, 19,
23, 27, ..., previous+4, ...}, so a filter of length 22 isn't a half-
band filter.
Dirk Bell
Article: 141771hvo wrote: > Hello, > This might not be the best place to ask but i'd thought to give it a > shot. > > I am running a webserver on a spartan 3an FPGA. My webserver uses yahoo > scripts to listen to a submit button with the YAHOO.util.Event.addListener > command. Then it gets some data in the FPGA and displays it on a page. My > question is how do I get it to automatically submit the request without > having to press the submit button everytime? there are several ways, mostly based on HTML/HTTP ideas (like the "refresh" meta tag, just google it) or with a more complex AJAX method (XMLHttpRequest) that is called every X second by a client-side page that your server hosts. I have also imagined a version where the page is never ending loading, which updates your data, but your browser's cache may dislike it. > Thanks for any sugestions > HV yg -- http://ygdes.com / http://yasep.orgArticle: 141772
Hi everyone. I'm trying to learn more about how configuration of an FPGA works. I have been looking at data sheets of integrated boards such as Opal Kelly, but I wasn't able to get much information. My question is: In boards where a bitstream is sent every time after power-up, where is the configuration bitstream stored? Is PROM or Flash required for storing it? Is a CPLD or something similar needed to manage the configuration of the FPGA? If the configuration is not done by JTAG but by sending the bitstream through USB or PCIe, how is the bitstream recognized as a bitstream? It'd be nice if you can point me to any resources concerning this too. Thanks in advance!Article: 141773
Hi! Q.1. I have few questions. I want to know which is the most efficient multiplier algorithm which can be implement on FPGA? I used core generator for multiplier but it utilizes more CLB as i needed. I want efficient and area constrained algorithm. Is there any algorithm considering the efficiency both in area and timing? Q.2. I need to know that is square root in fpga core uses CLB or it is hard IP? Regards RaiArticle: 141774
Rai <raifasih@gmail.com> wrote: > Q.1. I have few questions. I want to know which is the most efficient > multiplier algorithm which can be implement on FPGA? I used core > generator for multiplier but it utilizes more CLB as i needed. I want > efficient and area constrained algorithm. Is there any algorithm > considering the efficiency both in area and timing? If you aren't in a hurry you could do an iterative multiplier which generates some number of product bits per clock cycle. You can multiply an M bit number by an N bit number in M clock cycles with an N bit adder and 2N bit shift register, for example. > Q.2. I need to know that is square root in fpga core uses CLB or it is > hard IP? There are iterative square root algorithms, too. Well, most are, but there are convenient shift and subtract algorithms for simple hardware implementation. -- glen
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z