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

Subversion Repositories dblclockfft

[/] [dblclockfft/] [trunk/] [bench/] [cpp/] [butterfly_tb.cpp] - Rev 30

Rev

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

Filtering Options

Clear current filter

Rev Log message Author Age Path
30 Minor documentation edits. dgisselq 3099d 07h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
29 Checking in a lot of changes here. These changes were focused on two
things primarily: 1st the ability to match, in bench testing, the bench
test to the configuration of the generated FFT. For this purpose, the
fftgen program now creates fftsize.h and ifftsize.h header files. These
header files contain the parameters that were used in the creation of the
various verilog files, and therefore the C++ test benches may now be compiled
to match the test files. The 2nd change is the multiply. Based upon a
set of slides from Xilinx, I rebuilt my shiftaddmpy into a longbimpy.
(Think if 'bimpy' as a 'bi', or two-bit, 'mpy', or multiply.) Longbimpy
depends upon bimpy, an optimized 2xN bit multiply--optimized for 6-bit
LUTs with carry chains. Longbimpy simply expands that capability to a
NxN bit multiply. Sadly, the longbimpy approach increased my area on the
chip when it was supposed to be a cheaper multiply, so I may well take it
back out in the future.
dgisselq 3255d 16h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
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 3287d 17h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
23 Lot's of work to implement a variable means of rounding. The variable
rounding is now implemented within the code, all that's left is to
place a command line option to the generator to choose how values
are to be rounded: either by truncation (drop the lower bits), by
always rounding half up (if the first extra bit is one, go up),
by rounding away from zero (if exactly .5, move away from zero), or
by rounding towards even (if exactly .5, move towards the nearest
even value).

This added an extra clock cycle to each stage, so all of the
test benches needed to be reworked. There is currently no testbench
to test the rounding method itself. This necessitated some
wholescale changes to the testbench code, and the addition
of the twoc.[h|cpp] files. (They were within every piece of code, just
copied from one to the next, this now encapsulates them within their
own file so fixes will propagate to all.) Other changes include creating
testbench classes, adjusting the classes so that one can test what will
happen if the sync isn't added initially, and more. In the end, my
problem was tied to an assumption within fftmain.v that dblstage would
always be a one tick delay, whereas with the one tick of the rounding
function it now becomes a two tick delay .... but the task is done, and
the FFT appears to work again. The maximum sum of square errors (XISQ)
is about half what it was before now, when I use convergent rounding.
dgisselq 3367d 08h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
15 Added rounding into the routine to remove bias. All of the test benches have
been modified so that the FFT, with rounding, now passes. While the rounding
implementation applied does remove bias, it does not yet remove all bias.
Some work still remains.
dgisselq 3374d 07h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
13 I updated the butterfly testbench to automatically determine the delay
internal to the chip and multiply, and then to use that delay in determining
whether the values were accurate or not. This is better than the fixed
delay approach that was used before. The change was necessitated by an
attempt to use a different multiply structure that had a different
internal delay to it. (The multiply didn't work out, as it only worked
on operands with identical numbers of bits.)
dgisselq 3375d 11h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
8 This completes the initial work on a test bench for the FFT stage. I
chose to test the odd 2048 stage only, but (hopefully) the testbench
will still apply to all other stages as well. At any rate, based upon
some trial runs, it looks like the FFT may be starting to work as well.

More testing is needed, for certain, but to do that I'm going to have
to figure out just what tests are needed, and how exactly to apply those
tests within the test bench construct.
dgisselq 3381d 18h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
6 Lots of work accomplished today. Test benches now exist and work for the:
butterfly, multiply, bitreversal, pairwise FFT stage (dblstage), and the
four-wise FFT stage (qtrstage). Work continues on the single (generic)
FFT stage, and (of course) the FFT isn't ready yet. A second commit will
follow this one shortly with the new files added (oops!--I should've added
them this time--my bad.)
dgisselq 3382d 04h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
5 The butterfly_tb is now written, and the butterfly succeeds at the test
bench!
dgisselq 3382d 12h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
4 Bench tests updated, they now state SUCCESS upon successful completion,
return a 0 on success, and all bench tests test all function outputs
(now).
dgisselq 3382d 17h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp
3 The first upload of the s/w didn't take. Had it taken, the comment would've
been: This is the first upload of the double clocked FFT software. While it
should (roughly) be complete, a lot of work remains to be done--primarily
in building test benches, modifying the interface of fftgen to make it
more friendly, etc. In fact, the c++ code not only compiles, but the
Verilog code it produces actually builds as well!

Now, however, I have several test benches written, and have verified the
unit functionality of the multiply, bit reversal stage, the dblstage (FFT
len 2), and the qtrstage (FFT len 4). I then took a closer look at the
multiply, discovered it failed at signed integers and rebuilt it. The
new test bench tests the full 16-bit signed integer support properly. This
leaves butterflies and generic FFT stages that still need test benches, as
does the main (I)FFT program.
dgisselq 3382d 17h /dblclockfft/trunk/bench/cpp/butterfly_tb.cpp

powered by: WebSVN 2.1.0

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