FPGA: 2^n Moving window average: Request for peer Review

[tartan5]

Hello,

I am developing a 2^N Moving Window Averager for LV FPGA.  I am interested in getting feedback......Simpler methods, ways to wire which would be simpler to understand, as well as (perhaps even most importantly) optimizing the code such that it is more resource efficient.

Notes:

1) The intention is that this VI will run inside a Single Cycle timed loop.

2) Changing N is blocked until the Reset input is asserted.

3) Don't mind the bizzare input size (34 bit Signed).....I wrote it this way since that is what I need . 

4) Labview FPGA and the "Fixed point library for Labview FPGA"  are required

5) With N=2, the sequence 1, 1, 1000, 1, 1, 1, 1 should  = 1

Looking forward to your insight........

Howard

Message Edited by tartan5 on 04-05-2008 04:24 PM

[Aashish_M]

Hi Howard,

You might want to have a look at the averaging examples in IPNet - LabVIEW FPGA Functions and Example IP. It's a great place to look for FPGA IP and examples.

Hopefully this helps!!

[tartan5]

Hi Aashish_M,

Thanks for pointing me to the ipnet area, it looks like a great resource.

However, none of the averagers in the IPNET suit my needs.  I plan on submitting my vi to the ipnet forum.

2^n point-by-point average - Not a moving window average, just averages 2^n points......

2^n Point moving average -

     A) Can't handle FXP (Esp anything bigger than 32 bit)

     B) Has flaw - Change of N results in erronous results but data valid still true

8 point Average -

     A) Only does 8 points 

     B) Can't handle FXP

My vi can be customized for any bit size (within FXP range), does a true moving-window average, can be reset, and blocks changes to N until a reset occurs to prevent erronous results........

Hopefully someone other than me will find it useful......

Thanks!

Message Edited by tartan5 on 04-08-2008 07:07 AM

[Aashish_M]

Hey Howard,

You should definitely post it in IPNET. I am sure there are a lot of people that will find this useful.

[sducs78]

I'm actually using this VI on a FPGA target with minor modification to average four FPXs (signed I36.36) at 1 MHz with a depth of 128 points (2^7) and improve resolution of my measurement (signed FXP I44.36). Everything is working fine but today it is no more sufficient and I would like to improve the average depth by improving the number of delay.

Does anyone have an idea on how to replace the delay function by something similar but not limited to 128 points ? Does anyone know how this function is working ?

Thank you in adavance for your help

Sebastien

Message Edité par sducs78 le 05-06-2010 10:20 AM

[Online_Courses]

Deleted post

Message Edited by Online Courses on 05-10-2010 03:29 AM

[Aashish_M]

Hey Sebastien,

I haven't used this filter, so I am not sure of the inner workings.

Have you tried adjusting for a a higher order filter?

What results do you get when you try a value higher than 7?

[sducs78]

Yes, I tried to increase n but the result is not correct, as if something was truncated. In fact, I don’t really know what happened into the Z^-n sub vi, the source is not open, so it's not easy to find where the problem is. One thing is sure, the vi help states that n mustn’t exceed 7 (maximum delay = 127 = 2^7-1). This is the reason why I’m looking for another solution !!

 

[GtodaG]

@sducs78: Have you tried more than one of these delay blocks in series? I haven't tried it myself but it seems like it would work.

I've been using this VI with success. However I did modify the number of bits used for my application, and i was getting weird results at first. My averaged value would very slowly drift downwards over time.Turned out that I didn't add enough of a buffer the the number of bits for the result. For example my data type is word length 26, integer 5. Since this gets summed up 2^N times, the sum and subtract blocks have to be able to handle a big enough number. I just made the output of the sum and subtract to be 8 bits longer, so 34 and 13. This solved the problem.

Of course if you stick in some extra delay blocks you'd have to add a bigger buffer.

[tartan5]

Hello Everyone,

I'm glad to see that this VI has been helpful to some people.  I think GtodaG is correct, you should be able to cascade additional Discreet Delay elements (Z^-n blocks).  Keep in mind that as n increases, the variables have to accommodate n additional bits.

Also, each discreet delay can only add, at most, 128 delay elements. To get n=8, or 256 delays, you need two Z^-n blocks.  To get n=9, or 512 delays, you would need 4 Z^-n blocks.  While it seems like we should be able to get finer resolution than 2^n delays, especially as n gets larger, this VI works because dividing by 2^n is easily accomplished in one clock tick, whereas dividing by, say, 33 is not so trivial.  Remember this was written in LV8, and was designed to run within a single cycle timed loop.

Hmmmm.....Also remember that if you cascade the DD blocks, your minimum delay would be = the number of blocks (one delay per DD block), assuming you divide the active delay elements between the cascaded DD blocks.  For example, for 256 (max) delays, you would use 2 DD blocks.  You then send (2^((buffered n) - 1)) - 1 to each DD block to configure each block to process 1/2 of the incoming data.  In this case you need to ensure that (buffered n) >0 but < 9.  So, if (buffered n) = 5, we want 32 total delays.  2^(5-1) - 1 = 15, which we send to each DD block, for 16 delay elements each = 32 total.  If (buffered n) = 8, then the # delays = (2^7 - 1)  = 128 delays x 2 = 256 total delays. 

If you do some additional gating, you should be able to bring the minimum delay value back down 1.  This would require fully utilizing each DD block in succession, then deciding which DD block to pick the output value from to subtract from the running total.  For example, if n is between 0 and 7, the output from the first DD block is subtracted.  If n=8, then from the second.  If N=9, then from the FOURTH, if N=10, then from the EIGHTH, etc.  I'm not sure how far you can go before you run out resources on the FPGA target.

I wish I had my system here to code this up, but my development computer has been "reassigned", and I'm not sure when I'll get a development system back up and running........

Note that things may have changed for LV10, a quick look shows that the DD blocks can now go out to 512 elements??????

Hope this helps, if anyone has any further questions I would be glad to help as much as I can without a development system......

Regards,

Howard