| Rev |
Log message |
Author |
Age |
Path |
| 41 |
Updated bench tests for each component |
dgisselq |
1888d 13h |
/dblclockfft/trunk/bench/ |
| 40 |
Updated SBY files for formally verifying the FFT |
dgisselq |
1888d 13h |
/dblclockfft/trunk/bench/ |
| 36 |
Added several new modes to the FFT
This makes the FFT core generator a generator for a generic
pipelined FFT--whether it be two samples per clock, one
sample per clock, one sample per two clocks, or even one
sample every three clocks.
This version works in simulation, with some formal checks
as well. |
dgisselq |
2147d 18h |
/dblclockfft/trunk/bench/ |
| 35 |
TB now handles newer Verilator versions
I also placed verilator -Wall into the verilator Makefile,
turned on the -trace capability (tho nothing uses it), and
placed `default_nettype none into all of the created
Verilog files. |
dgisselq |
2362d 02h |
/dblclockfft/trunk/bench/ |
| 33 |
Updated internal docs, ignore files, no substantial changes. |
dgisselq |
2608d 22h |
/dblclockfft/trunk/bench/ |
| 32 |
Fixed the makefile dependency on the static VERILATOR_ROOT. |
dgisselq |
2770d 17h |
/dblclockfft/trunk/bench/ |
| 30 |
Minor documentation edits. |
dgisselq |
3085d 15h |
/dblclockfft/trunk/bench/ |
| 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 |
3242d 00h |
/dblclockfft/trunk/bench/ |
| 28 |
This revision represents a lot of work to get the Verilator simulation to now
match the FPGA performance. The big problem turned out to be in the
bit reversal stage, where a '=' was used on a register instead of a '<='.
Neither Verilator nor Vivado complained, but they each treated the result
differently. In addition, a bug was traced to the soft butterfly, butterfly.v,
whereby the delay through the butterfly did not properly change when the
delay through the multiply changed. All of this has been fixed, and now
appears to work and work well in both hardware and simulation. |
dgisselq |
3251d 18h |
/dblclockfft/trunk/bench/ |
| 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 |
3274d 01h |
/dblclockfft/trunk/bench/ |
| 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 |
3353d 16h |
/dblclockfft/trunk/bench/ |
| 22 |
Lot's of changes, mostly around getting this multiply to fit within a
particular FPGA. Specifically, we just added the capability of using
hardware multiplies to the command line options. Use them if you have
them, and it will simplify the operation of the FFT. |
dgisselq |
3354d 18h |
/dblclockfft/trunk/bench/ |
| 19 |
Added the capability to accumulate bits internal to the FFT, only to drop
those extra bits just before the end. This helps to reduce truncation
error, and may even drop it by a factor of four (my own measurements). |
dgisselq |
3358d 00h |
/dblclockfft/trunk/bench/ |
| 18 |
This file was placed into the bench/rtl/ directory. |
dgisselq |
3359d 16h |
/dblclockfft/trunk/bench/ |
| 17 |
These files were moved here from the trunk/bench/cpp directory, as they
seem to make the most sense here. (They're not C++ files, but Verilog
files, supporting the testbench functions.) |
dgisselq |
3359d 16h |
/dblclockfft/trunk/bench/ |
| 16 |
Cleaned up the test bench build scripts, made sure license statements were
placed on all files, etc. |
dgisselq |
3359d 16h |
/dblclockfft/trunk/bench/ |
| 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 |
3360d 15h |
/dblclockfft/trunk/bench/ |
| 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 |
3361d 13h |
/dblclockfft/trunk/bench/ |
| 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 |
3361d 19h |
/dblclockfft/trunk/bench/ |
| 9 |
Now working on the test bench for the FFT. Currently, the FFT passes
all test bench "tests." However, the test bench does not yet accurately
report on the success of its work. This remains for future work. Lots
of bugs fixed while making this test bench code work.
(I should mention, while all test benches currently pass, that doesn't
mean that the code works ... yet. I just haven't found the bug that
breaks it.) |
dgisselq |
3367d 18h |
/dblclockfft/trunk/bench/ |
