OpenCores

URL https://opencores.org/ocsvn/dblclockfft/dblclockfft/trunk

Subversion Repositories dblclockfft

[/] [dblclockfft/] [trunk/] [bench/] [cpp/] [fft_tb.m] - Rev 26

Go to most recent revision | Details | Compare with Previous | Blame

Filtering Options

Rev	Log message	Author	Age	Path
26	A lot of updates and upgrades in this release. Specifically, work took place over the last several days to demonstrate this FFT on an FPGA. It was demonstrated on the Xilinx Artix-7 found on a Basys-3 development board. Part of the effort stemmed around making certain that the DSPs were used optimally, part of it stemmed around making certain that various parts of the FFT could use block RAM-type memories. The other massive change involved removing as much unnecessary logic as possible, so that two 16-bit 1k FFTs could fit onto this part--together with other glue logic. The bottom line, though, is that it all now works. Specifically, I've tested it successfully with fftgen -f <FFTSIZE> -n 16 -m 16 -p 7 -c 1 -x 1 and with FFTSIZEs of 32, 64, 128, 256, 512, and 1024. Oh, I should mention that there's also an undocumented DEBUG interface to the part, and I fixed where the Verilog files went when given an argument, so that they actually went to the directory specified. Minor updates have taken place to the documentation format, making it match the documentation format for other opencores projects that I've produced. On a sadder note, the Verilator simulation fft_tb no longer works. (Yeah, get that---the FFT implementation works but Verilator does not. Sigh).	dgisselq	3288d 00h	/dblclockfft/trunk/bench/cpp/fft_tb.m
14	Found several bugs in the previous version. The biggest were in the qtrstage. Apparently, the qtrstage didn't work before, even though I thought it did. Further, the FFT testbench has been adjusted to place proper values into the fft_tb.dbl file it creates. (I've been testing it by reading this into Octave, and visually inspecting the results--quantitative testing of the fft_tb and ifft_tb are still lacking.) Now, however, if I cascade the forward and reverse together, I seem to get something at least close to the right answer. Close, of course, is relative. I think all that I still struggle with is rounding and truncation errors, hence I'm checking in my changes. The FFT generator was also modified to allow arbitrary length paths in the command line specified path prefix. This has not been tested. A bug was also found in the butterfly, whereby for certain multiply delays the butterfly would be unable to determine whether or not its results were valid. Adding an extra bit to the FIFO address in these cases fixed the problem. This change was encapsulated into the lgdelay() function, and an additional bflydelay function. In my frustration, I modified the fftstage function so that, when it is built, the parameters it is built with are the default parameters. This should only affect testing, by making any testing more realistic, but that may still remain to be seen. Another change was made to the core generator, so that now when a core is generated, the main file now contains a copy of the arguments that were used when the core generator was invoked. This is good for posterity, in case you ever need to ask yourself how I ended up here.	dgisselq	3375d 12h	/dblclockfft/trunk/bench/cpp/fft_tb.m

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.