FPGA Mod for signal averaging takes too many resources

[jmadsenee]

Hi All,

I obviously don't really know what I am doing. I made a mod to the fpga to do signal averaging (as opposed to the point averaging for decimation). I modelled it on the averaging in the decimation section, but with indexing. Basically, it seems that instead of implementing it in BRAM, the synthesis tried to implement it in LUTs and Memory LUTs. The LUT Utilization went from 26% to 180% and Memory LUT Utilization went from 3% to 378%. FYI - I removed the daisy chain and test parts of the code. I've attached the red_pitaya_scope.v file. If someone could take a quick look (ADC buffer RAM section), and tell me what I did wrong, I would greatly appreciate it.

Thanks!

John

[Nils Roos]

I did take a quick look, and I would offer the following preliminary analysis:

To accumulate data in BRAM, you need to read AND write in the same clock cycle. Additionally, you have to support read accesses to move the data over to the ARM cores. That is a total of three simultaneous operations that the RAM would need to process, but the BRAM blocks are "only" dual-ported.

I suspect that if you were to multiplex the read side between accumulation and read-out and do either one or the other depending on some flag, Vivado might be persuaded to use BRAM again.

[jmadsenee]

Hi Nils,

Thanks so much for the advice. That solved my problem, and I am able to signal average!

Unfortunately, now my timing warning has come back. I had gotten rid of it by removing the daisy chain and test code as you had also suggested. I tried several different implementations and all had the timing warning. Attached is the scope.v file with 2 of the implementations. I am not an FPGA guy, and so I'd be willing to pay someone if they could get rid of that timing error for me...

OK, well, I tried to upload the file as a .tar.gz and a .zip... Kept getting a message: Could not upload attachment to ./files/906_08bb80abd18fa05358ba2fbce4fd8a06.

John